happens if all of the following are true:
1) You use link::outgoing::tls-options (or ssl-options)
2) You do a REHASH -tls (or REHASH -ssl)
3) You do NOT do a regular REHASH
4) You try to link to the server in such a link block (outgoing!)
In other words: the problem may happen if you try to link after
a Let's Encrypt cert renewal, unless there has been a regular
REHASH between that and the outgoing linking attempt.
Reported by k4be and Le_Coyoto in https://bugs.unrealircd.org/view.php?id=5607
depending on the module load order. Reported by k4be.
Changes:
* Websocket hooks:
* Input should be run first
* Output should be run last
* Labeled-response also had various hook priorities wrong
* Pre command should be run near-first
* Post command should be run near-last
* Close connection (does the flush) should be run near-last
* Packet should be run near-last
Previously it didn't display correctly on server notice the TLSv* version on local connection.
Before: TLS_CHACHA20_POLY1305_SHA256
After: TLSv1.3-TLS_CHACHA20_POLY1305_SHA256
set {
anti-flood {
target-flood {
channel-privmsg 45:5;
channel-notice 15:5;
channel-tagmsg 15:5;
private-privmsg 30:5;
private-notice 10:5;
private-tagmsg 10:5;
};
};
};
Max 45 messages in 5 seconds means max 540 messages per minute,
with a peak of (surprise) 45 messages per 5 seconds...
That should be sufficient for every legit channel, right?
How can you chat if you get more than 9msgs/sec for 5 seconds straight?
Maybe I am even too liberal with these limits?
NOTICE and TAGMSG get lower limits because they are far less used
and have other concerns (eg: ringing a bell for NOTICE).
The default limits may be changed in later versions of UnrealIRCd
based on feedback and more insight in (big) channel rates.
This provides ROP hardening, which is actually quite nice.
However, it requires CPU hardware support, which is pretty
non existant at the moment. So, right now, on most systems
this option will do nothing.
This is 1,5 years after 459a55245a
and we're on a new series too (5.0), so it was about time.
And YES you may still use }; if you want to. There are no
plans to deprecate or warn about it.
We simply ship with } in the shipped configs because it is
more logical that both { and } don't require a ; rather
than only { not requiring it.
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.
Bram Matthys