version or newer on the sytem, otherwise we fall back to shipped version.
This fixes https://bugs.unrealircd.org/view.php?id=5187 among others.
It means:
* Case insensitive matches work better in UTF8 now, such as extended Latin.
For example, a spamfilter on "ę" now also matches "Ę", while previously
it did not catch this.
* Other PCRE2 features such as https://www.pcre.org/current/doc/html/pcre2syntax.html#SEC5
are now available. For example you can now set a spamfilter with the regex
\p{Arabic} to block all Arabic script, or
\p{Cyrillic} to block all Cyrillic script (such as Russian)
Use these new tools with care, of course. Blocking an entire language,
or script, is quite a drastic measure.
All of this was possible because of the new PCRE2_MATCH_INVALID_UTF
compile time option which was introduced in PCRE2 10.34.
This also means we now require at least that PCRE2 version so
everyone can benefit from this new spamfilter UTF8 feature.
Many systems come with older PCRE2 versions so this means we will
fall back to the shipped PCRE2 version in UnrealIRCd. This means
./Config will take a little longer to compile things.
Although there is no indication as of now, but if this feature would
break things heavily then it might get reverted or configurable.
This is also why it was added just after 5.0.4 release and not right
before it, it needs some heavy testing.
TLSv1.0 or TLSv1.1. Otherwise it is impossible to enable by the application.
We are still going to turn off TLSv1.0 and TLSv1.1 by the end of this year
by default. Ubuntu 20.04 is just a couple of months too early. See also
the various browsers who postponed disabling TLSv1.0/TLSv1.1.
Also, regardless of the above, we want the admins running the IRC server
be able to control this and not having such a breaking change be dependant
on some distro default settings.
We will extend the option later in UnrealIRCd 5.0.5.
This purely has to do with keeping the changes for 5.0.4 small and
contained since that will be mostly a bug fix release.
Since 5.0.5 will have more configurable options for hide-idle-time, I
have already renamed the single option that is exposed in 5.0.4
to set::hide-idle-time::policy since set::hide-idle-time is a
configuration block now, see docs at:
https://www.unrealircd.org/docs/Set_block#set%3A%3Ahide-idle-time
When connecting, use slightly different wording (and use it consistently):
"Trying to activate link with server xyz"
When the connection is lost before synced:
"Unable to link with server xyz"
When the connection is lost after fully synced (eg: minutes later):
"Lost server link to xyz"
Important small changes (other than text):
* Log ERRORs from remote servers to the log (previously only shown to ircops)
* Some link errors could have been previously suppressed due to
old code assuming other parts of the code would send or log the error
(this would be the case for an error when calling SSL/TLS write functions)
* More?
I think nowadays, with more attention to privacy, we should make this
option settable by users.
See previous commit for more information, or just visit the doc page at
https://www.unrealircd.org/docs/Set_block#set%3A%3Ahide-idle-time
if you want to use a different setting.
connected users for technical reasons, so you will have to use double
whois to see it for remotes (/WHOIS Nick Nick) just like with idle time.
Suggested in https://bugs.unrealircd.org/view.php?id=5519
set::ident::connect-timeout for the read timeout also.
This could lead to failed ident lookups on higher latency connections
because it only gave 3 seconds for the entire ident lookup rather than
the (max) 10 seconds that was intended.
Now both values are properly obeyed (3 for connect, 7 for read
timeouts, by default).
This only happens in some circumstances.
From now on EventDel() will simply mark the event as deleted.
The actual freeing is started in DoEvents() after the event loop.
This makes it safe to use EventDel() everywhere.
The previous attempt to fix that issue was
d29a55a8db but it introduced a
new crash issue for a slightly different case, as mentioned in
https://bugs.unrealircd.org/view.php?id=5553
when used on a multi-server network. This was due to the PART event
inadvertently not being sent towards the SAJOIN direction.
Bug reported by Cheiron in https://bugs.unrealircd.org/view.php?id=5616
form an insecure connection. There we explain a bit on the why and how to
configure some random IRC clients.
This also silently adds support for multi-line messages in
set::plaintext-policy::user-message (for warn) and
set::plaintext-policy::oper-message (for warn and deny).
Eg with anope with the KILL option turned ON, a minute after taking
a registered a nick.
Very similar to c9b88343e2 which was
fixed in 5.0.0-beta1 for non-forced nick changes.
files that end in .core, while on many systems it is just 'core'
without the dot. Reverted back to U4-style core file finding now.
Thanks to DeviL for helping to trace this issue.
and HOOKTYPE_REMOTE_CHANMODE are called from the SJOIN code.
We now set the samode argument to -1 if it is an SJOIN server sync,
so chanmodes/permanent won't destroy the channel while processing
the SJOIN. The SJOIN code already takes care of destroying at the end.
so they can fetch more history than the standard on-join history.
In the future we are also likely to implement IRCv3 CHATHISTORY
once that becomes an official specification. However, until it is
specified and until most major clients support it, several years
are likely to pass. It would be a shame to withhold channel
history to many end-users in the meantime when it takes so little
effort from us to provide an easy command.
See also
https://www.unrealircd.org/docs/Channel_history
And in particular the new section:
https://www.unrealircd.org/docs/Channel_history#Playback_frontends
which explains the relationship between on-join playback,
HISTORY and CHATHISTORY.
Bram Matthys