Also, remove unnecessary comment about calling lr_post_command() with
the last two arguments being NULL. We don't use these two variables
inside lr_post_command() after this change anyway.
Then the oper may decide if the original entry should indeed be
removed and re-added, or if (s)he should not touch it. These are
usually done by mistake anyway.
Updating existing entries by end-users was never intended and did
not work properly anyway (see bug comments). Issue reported by
Le_Coyote and armyn in https://bugs.unrealircd.org/view.php?id=5603
This had to do with the queued packet (in the labeled-response module)
not being sent because the client was freed before the
post packet hook was called.
any parameter channel mode module loaded after channeldb.
Reported by GaMbiTo, with help from PeGaSuS, Gottem and k4be
in https://bugs.unrealircd.org/view.php?id=5669
It is not safe to call channel mode parameter functions when
unloading modules. Makes sense I think.
We now no longer write the db on rehash, which is something i
didn't like anyway (wasted CPU cycles). The problem was that
one could not just scratch the write db call, as otherwise if
someone rehashes every minute would cause the db never to
be saved. This is because on each rehash the event to write
the db gets rescheduled to +5 minutes in the future.
We now work around that in the same way as connthrottle does.
Obviously it would be better to make the event system itself
deal with this, but that is (way) too much for now.
This was a FIXME item that should have been addressed earlier.
We didn't use any MODDATATYPE_CHANNEL in the core up to now so
this was overlooked. We do use it from now on, though, and it
may very well have been used in 3rd party modules already.
This is the work from May 3rd.. need to commit it so i can merge the
flood protection that is related to this...
The final implementation will still need tweaking before pushed.
[skip ci]
no connect-delay restriction. Also remove the 'disable' option since
it is unneeded. You now simply use:
set {
restrict-commands {
somecommand {
}
}
}
...and the command is disabled.
And you add exempt-identified or exempt-reputation-score if needed.
See https://www.unrealircd.org/docs/Set_block#set%3A%3Arestrict-commands
Note that this also changes some command blocking logic, so I hope
I made no mistake there... only testing will tell.
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
Bram Matthys