1) Warn when >= July 1, 2022 that we only do security fixes (but continue the report)
2) Error when >= July 1, 2023 that all support ceased (do not send a report)
3) Handle HTTP 403 condition
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().
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
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.
(often completely unrelated to channel history) and you then rehashed again
UnrealIRCd would crash. Reported by gh0st.
May be the same issue as reported by adamus1red in
https://bugs.unrealircd.org/view.php?id=5943
This has to do with SavePersistentPointer/LoadPersistentPointer calls
which normally work fine but this particular module uses it in MOD_TEST
causing a certain sequence of events causing a double free or read-
after-free if you do it slightly differently.
later fd_close() call. This also removes fd_map() since fd_open w/FDCLOSE_NONE
now does that.
* If you use fd_socket() or fd_accept(), then no change.
When fd_close() is called we call close() on *NIX and closesocket() on Win.
* If you use fd_fileopen(), then no change.
When fd_close() is called we will call close() on both *NIX and Win.
* If you used fd_open() and then fd_unmap() because you didn't want us
to close the socket, then use fd_open() with FDCLOSE_NONE and
just call fd_close() instead of fd_unmap().
We will not actually close the fd in fd_close() (FDCLOSE_NONE).
* If you called fd_open() with other intentions then either specify a
FDCLOSE_SOCKET / FDCLOSE_FILE as the last argument, or more likely:
don't use fd_open() at all and use fd_socket() or fd_fileopen() instead.
For reasons on this change, see previous patch. This way is more sane and
makes it harder to make mistakes even beyond Windows-specific issues.
This fixes a file descriptor leak in Windows that happened in the
logging code. The most visible effect of this was if you had a
log::maxsize set then on Windows you would see:
"Max file size reached, starting new log file"
Every other line, forever (and not actually starting a new log).
fd_close() previously did not close the file descriptor of a file
on Windows because on Windows it needs to call close() for a file
and closesocket() for a socket, and it always did the latter.
On *NIX it's more easy and you can just always close() any fd.
if on OpenSSL 1.1.1 or later.
We trust OpenSSL 1.1.1 and later to be good enough to handle all
the reference counting and freeing nowadays, which is something that
was not done correctly in (much) older OpenSSL versions, leading
to crashes on one hand and on memory leaks on the other hand.
In OpenSSL 1.1.0 and earlier we do not rehash tls on simple "REHASH",
since that code has not been vetted. However, nobody should be
running those old OpenSSL versions anyway, since they are out of
official OpenSSL support.
Based on previous reports and patches from k4be in
https://github.com/unrealircd/unrealircd/pull/129
Looks much cleaner now.
This also filters out the edge case where user_account_login()
could have been called when a user transitioned from "not logged in"
to "unconfirmed account". It did not cause any issues AFAICT but
it is not really expected either.
services account.
This adds set::authentication-prompt::unconfirmed-message with
a default of:
unconfirmed-message "You are trying to use an unconfirmed services account.";
unconfirmed-message "This services account can only be used after it has been activated/confirmed.";
See https://www.unrealircd.org/docs/Set_block#set::authentication-prompt
Note that this is only shown for services which allow SASL from
unconfirmed services account in the first place, like atheme.
Anope does not allow it, which is something that could very well
be considered 'correct' as well. In that case you would simply
get the "Authentication failed" message instead
(set::authentication-prompt::fail-message).
https://bugs.unrealircd.org/view.php?id=5925
This does two things in cmd_uid() now:
* It checks if parameter 6 in UID is a valid UID, using valid_uid()
* It checks if the first 3 characters of the UID match the SID
Modules can still opt-in via mreq.remote_write=1 to allow it for
certain moddata.
For example, k4be may want to do this for his geoip-base module which
allows a single server to set moddata "geoip" for all connecting clients,
including remote clients.
If you are a moddata provider then you can enable it like this:
ModDataInfo mreq;
[..]
#if UNREAL_VERSION_TIME >= 202125
mreq.remote_write = 1;
#endif
[..]
See discussion on https://github.com/unrealircd/unrealircd/pull/142
This also allows known-users to execute slightly more commands per second.
For people who want their trusted users/bots to allow even more commands
per second (eg 20cmds/sec) we now have a nice FAQ item that uses this:
https://www.unrealircd.org/docs/FAQ#high-command-rate
Bram Matthys