AddHeader wrote its arguments straight into the response stream. No
in-tree caller reaches it with attacker-controlled bytes today, but the
public API is exposed to module authors; one bad caller would be a
header-injection bug. Filter at the entry rather than at every caller.
cctz::parse into a microseconds time_point internally multiplies the
parsed seconds-since-epoch by 1,000,000 in signed int64. Years past ~292k
overflow, which is UB under UBSan or -ftrapv builds. In plain production
builds the overflow silently wraps and buffer playback shows a garbage
timestamp.
Reject anything with a year longer than 5 digits before calling into
cctz. 5 digits covers every realistic IRCv3 @time tag.
Without this check, when uIdx >= m_vsParams.size() and the vector is
non-empty, the subtraction in the clamp condition underflows to SIZE_MAX.
GetParamsSplit() already has the equivalent check at the top of the
function; this brings GetParamsColon() in line with it.
Fixes#1994
Use user configured network on the IRC client connection message example, so it turns from `/server <znc_server_ip> 1025 Admin:<pass>` to `/server <znc_server_ip> 1025 Admin/libera:<pass>`.
Should have done this from the start... 😅
When Goguma connects to ZNC, it joins the joined channels again and
again, triggering flood protection.
Note: even with this fix, the Goguma+ZNC experience is still pretty bad
and requires doing something about repeating chat history
It's unlikely server has nothing to send at all for all the other messages ZNC is sending and that there's nothing happening server-side too. But PING at least is guaranteed to give the response, so ZNC shouldn't disconnect too eagerly
ZNC remembers that it should join these channels, and will join them after registration. But if client automatically joins some channels, we don't want it to be added to send queue before parts of registration itself (CAP, AUTHENTICATE), because server will just disconnect with "Registration timeout". After registration is complete, using /join still joins the channel immediately.
Only limiting this to joins, because server may request some input from user to finish registration, and joins are the ones which are prone to be sent automatically by client to cause issues.
Fix#1949
This is a way for admins to mitigate some issues caused by caps if such issues ever arise.
E.g. add this to global level in znc.conf:
DisableClientCap = sasl
DisableServerCap = chghost
DisableServerCap = message-tags
Then these caps will be NAKed to client / not requested from server.
Note that this mechanism doesn't fully prevent a cap from being activated, e.g. one could use *send_raw module to request it from server even when disabled.
Alexey Sokolov