configuration. It was always cleaning up old entries after 2 minutes.
That is, until the first REHASH happened, after that the correct
connect-flood setting was applied.
In practice, with the default configuration, this means that instead
of 3:60 it was 3:120 until the first REHASH, and after that 3:60.
This was caused by update_throttling_timer_settings() being
called before init_throttling().
from https://curl.se/ca/cacert.pem. Has a few changes, but the most
notable change is that they removed DST Root CA X3. This fixes
verifying Let's Encrypt certificates if you use the "DST Root CA X3"
chain (which is currently the default in certbot and all) on:
* OpenSSL 1.0.2 or earlier (old but in use on eg: Debian 8, Ubuntu 16.04, ..)
* LibreSSL below 3.3.5/3.2.7 (so until a day ago)
This only affects outgoing connections, so for remote includes and
for server linking. Server linking is only affected if you use the
link::verify-certificate option, which most people don't use.
On a side note, ISRG Root X1, so the "real root" for Let's Encrypt is
already included since August 2017 (c8a67f9436)
This broke SASL services autodetection and also sasl=x,y,z in CAP.
Reported by Valware in https://bugs.unrealircd.org/view.php?id=5960
Of course the easiest solution would be just to set .remote_write=1
for this, which is what I've just done for the 5.2.1.1 release.
But there seems to be a pattern here. When a server wants to write
its own object (irc1.example.net writing to the MD object of
irc1.example.net) we have the problem that that object is both
"our client" and from the other server POV it is "themselves".
On one hand you may want to allow that (eg for 'saslmechlist'), on
the other hand a server writing its own 'certfp' sounds like a bad
idea in principle.
So we now add a new option for the 'self' case and make some MD
objects use it. In fact, in the core we now have zero MD objects
using remote_write. We keep the option available though, for example
for k4be's geoip modules and possibly future features.
Module API change:
* .self_write added which allows a server to write to its own object
(irc1.example.net writing to the MD object of irc1.example.net)
* .remote_write still exists too if you want to allow remote servers
to write to your own objects
* Note that in all cases, servers can always write to their own
(child) client objects.
Changes:
* The link-security MD changed from .remote_write=1 to .self_write=1
* The salmechslist MD now has .self_write=1, this fixes the actual bug
instead of standard wildcard.
In this case, since it's antirandom, it is not really important
as someone is not going to add DNS records specially to avoid
triggering antirandom. That makes no sense since it is much
easier to avoid using a random looking name.
Main reason of changing it here is to set a good example.
arbitrary hosts that have a host starting with "127.". A rather stupid
oversight on my part, really.
In the meantime, if this happens, then you can still resort to using
ZLINE/GZLINE as a workaround to ban such a user. (The exemption won't
match against the host because DNS lookups are not done for zlines)
Reported by armyn in https://bugs.unrealircd.org/view.php?id=5957
This was more of a oversight because the cmdbytes calculation happens
in a different function after message tags have already been processed.
Also, wasn't really important up to now since we only allow quite short
tags at the moment.
Instead of just counting these in cmdbytes, as would be the most logical
and easiest fix, we use a different strategy:
We use a separate counter for message-tags so clients benefit from the
"rounding down rule". In other words: the first xyz bytes give you
no extra penalty compared to before (eg they are "free"). Useful for
clients who use eg @label heavily.
By default this is 90 bytes for unknown-users and 180 bytes for
known-users. See lag-penalty-bytes in set::anti-flood.
Bram Matthys