Without this fix, on an IPv6-only host UnrealIRCd would give you:
[warn] /home/ircd/unrealircd/conf/modules.default.conf:309: Failed to download 'https://www.unrealircd.org/files/geo/classic/GeoIP.dat': Could not connect: Network is unreachable
[warn] Continuing anyway...
This fixes https://bugs.unrealircd.org/view.php?id=6249, which was
also similarly reported by progval in https://bugs.unrealircd.org/view.php?id=6073
This implements only a simple try-IPv4-then-IPv6 approach in case of
clear connect errors. There is no happy eyeball like approach (where it
gives IPv6 a 250ms head start and then tries IPv4 in parallel), if there
is really a 15sec timeout then it doesn't retry IPv6 either (in case you
have IPv4, there is a route, but packets end up blackholed), nor does it
try all IP addresses that the resolver returns (then again, that's not
strictly related to happy eyeballs or IPv4/IPv6).
That would require some major overhaul that is not planned in U6. If you
want better/great protocol support you can always enable cURL in ./Config.
Maybe a bit odd since only <10 things use this category but it makes it
stand out as a separate thing much better. As for a level (not that it
matters) it is between 'info' and 'warn'.
Without this on some new compilers this raises a warning (or error with -Werror):
const char hexchars[16] = "0123456789abcdef";
The alternative is to add __attribute__((nonstring)) at the various places
that need it. But 1) that requires various ifdefs to support old compilers, and
2) This doesn't catch anything meaningful in our code anyway and the odds of
it doing so seem slim.
users by server port (eg 6667, 6697, 8000, etc).
This also adds security-group::exclude-server-port for consistency.
And in crules the function server_port() returns the server port number,
so you can use rule 'server_port()>6690' for example.
Note that for remote clients this will only work after previous
commit (b2d0ec1af3) is loaded on all
servers, otherwise all remote clients are seen as having a server_port
of zero (0). Though you probably usually only care about this on local
users anyway.
Reported/requested by CrazyCat: https://forums.unrealircd.org/viewtopic.php?p=40990
Inspired by Valware's PR: https://github.com/unrealircd/unrealircd/pull/319
This adds "away_reason" and "away_since". Note that the latter may not be as
reliable for remote users at the moment, because in case there was a split and
the server (re)connects, the away_since will be the time of the server resync
and not the original time that the user went away.
In debug mode we also - in the JSON log - log the source file and
line number in every log message. This requires special care. A good
start was made earlier but that fix was incorrect.
Should be good now... at least when i ran tests the leak that was
previously there was gone.
The original issue was that I used (again, only in DEBUGMODE):
#define unreal_log(...) do_unreal_log(__VA_ARGS__, log_data_source(__FILE__, __LINE__, __FUNCTION__), NULL)
But, some functions call unreal_log with something like:
unreal_log(.....
xyz ? log_data_client("xyz", xyz) : NULL);
And then the expanded function arguments may become:
NULL,
log_data_source(...)
And since it is a vararg list the first NULL already terminates it and the
log_data_source() is never iterated, stays unseen, and thus stays unfreed.
A fix for that was made in 42caa34b5c:
do {
LogData *lds = log_data_source(__FILE__, __LINE__, __FUNCTION__);
do_unreal_log(__VA_ARGS__, lds, NULL); log_data_free(lds);
} while(0)
but in practice we still freed at the wrong place... it was still being
freed in the do_unreal_log() (or a child) function and the log_data_free()
actually didn't free anything.
All that is now fixed in this commit.
in the EFunction but not in the actual function. That's bad since it
means the "const guarantee" got lost. And one or two similar cases with
incorrect parameter types and mismatching return types. This was
found with some analyzer, we had no bugreports with regards to this.
The 4 unicode blocks are now treated as one big Latin block
Latin-1 Supplement, Latin Extended-A, Latin Extended-B ==mapped=to==> Basic Latin
Reported by CrazyCat in https://bugs.unrealircd.org/view.php?id=6576
It could cause a spurious
"Your config has NO errors, but you received some best practices tips above, in summary"
even though no best practices were displayed... which was a bit mysterious.
Also, ::listen-nontls-port was actually meant to be called ::listen-tls-only
so accept both forms from now on. The reason it was supposed to be like that
is that all best-practices options are... best practices...
hashed passwords, trusted cert, trusted cert with valid hostname,
listening on a nontls port... ? NOPE! listen-tls-only! Aaaaa.
the default certificate/key (conf/tls/server.cert.pem) even when that
cert is valid and issued by a trusted CA (like Let's Encrypt).
You would get such an incorrect "best practices advice" on-boot, but
(fortunately) not on each subsequent REHASH.
This was because the TLS system was not yet initialized completely at
the time of the best practices checks, ctx_server was NULL. This is
now solved by re-ordering some function calls.
This does change some win_error() and config_load_failed() stuff for
Windows so I hope that's okay.
Reported by Bun-Bun.
* In 2016 we switched from OpenSSL to LibreSSL because the OpenSSL
codebase was in a bit of bad shape and LibreSSL promised to be a
more modern codebase. Now, almost a decade later, OpenSSL has had
many code cleanups and is more security aware (code audits etc),
especially since OpenSSL v3 things are looking OK and it seems
LibreSSL doesn't have much progress nowadays. Which is understandable
as they have a lot fewer coders available but has an effect on things
like how long it took for TLSv1.3 to appear and for other new things
like PQC. It also seems like security fixes are now slower than
OpenSSL instead of the other way around. Anyway, I think they did their
job well (together with other people) in "triggering" the OpenSSL
project to get things back on track. Let's switch back now.
* For context: it seems several Linux distro's that used to do go for
LibreSSL have also switched back to OpenSSL.
* LibreSSL is still and will continue to be a supported library to
use with UnrealIRCd (especially with OpenBSD and FreeBSD in mind).
So, if there are any issues (compile problems, configuration problems,
some feature not detected), then please report it on our bug tracker
at https://bugs.unrealircd.org/ ! We will have to rely more on such
user-reports now that the main devs will likely only work with OpenSSL.
Also... i have cleaned up the Makefile.windows a bit to be more consistent
Hopefully i didn't make a mistake there...
[skip ci]
requests normally, unless the niche feature set::allow-user-stats is used)
The tld::motd was made optional in Jun 2022 commit 1fe6119026.
Not setting it is probably a bit rare, which explains why this bug was only
reported yesterday (Aug 2025) via the crash reporter.
Just in case someone thinks we are going to msg users on plaintext ports
by default, no we don't that, or at least not this year.
This is purely a "best practices" advice to admins on config load.
[skip ci]
Isn't that what it was supposed to do? Well, yes and no, previously
it only guaranteed that between reconnects (so the 2nd try not being
before class::connfreq than the 1st try), but there were no guarantees
for the first time period directly after a squit.
* When a netsplit happens and
[set::server-linking::autoconnect-strategy](https://www.unrealircd.org/docs/Set_block#set::server-linking)
is `sequential` (which is the default) or `sequential-fallback`
(which is a good value for leafs) then we now consistently wait for
[class::connfreq](https://www.unrealircd.org/docs/Class_block)
seconds before trying to connect to the (same or next) server.
By default this is 15 seconds in the example configuration
server class. The reason for this is to provide a consistent behavior.
Previously we waited semi-randomly for 0 to class::connfreq seconds.
The previous behavior caused the picking of 'next server to try' to
be inconsistent, which especially caused issues for `sequential-fallback`.
If you want quicker recovery times in case of a netsplit, simply lower
the value of [class::connfreq](https://www.unrealircd.org/docs/Class_block)
in your configuration file, e.g. to 5 instead of 15 seconds.
Oh yeah and for connect-strategy 'parallel' things stay as is, with
the wait of 0 to class::connfreq per-server, which seems fine for that.
Unless you want a 'BOOM!' effect of mass reconnects instantly, in
which case you can just set class::connfreq very low.
That is, if the set::best-practices::trusted-cert check is on and passed
("certificate is valid and issued by a trusted CA") then we also
do this new set::best-practices::trusted-cert-valid-hostname check:
/* If the trusted-cert check passes, then we do another check to see if
* the certificate is valid for me::name. Since users usually connect to your
* server by your server name it is important for the certificate to be
* valid for that name. Unless you really only care about e.g. irc.example.net,
* and not about individual irc2.example.net server names, in which case you
* can turn this off, but not sure if that is good practice.
*/
trusted-cert-valid-hostname yes;
Expired: this is a warning, not an error (we still want to boot the ircd)
Expired: handle the case for link::verify-certificate explicitly to avoid confusion
Ports that listen on 127.0.0.1 or ::1 are ignored (useful for e.g. services)
Looks like this:
[info] You have at least one IRC plaintext port open (such as 5668). Nowadays, everyone should be using SSL/TLS (on port 6697). See https://www.unrealircd.org/docs/Use_TLS.
See that https://www.unrealircd.org/docs/Use_TLS for more info (feedback welcome)
All this is in addition to somewhat related 29ce0ce29a:
[info] Your SSL/TLS certificate is not issued by a trusted Certificate Authority.
[info] It is highly recommended to use a 'real certificate'. To get a free one, see: https://www.unrealircd.org/docs/Using_Let's_Encrypt_with_UnrealIRCd
If applicable, that message is printed first, the 6667 one comes after ;)
Suggested in https://bugs.unrealircd.org/view.php?id=6500
and numerous times / discussions on IRC over the past years
It's finally time.. no.. it's overdue..
/* Standard IRC port 6667:
* Insecure plaintext (NOT for production servers)
* This listen block is here only for quick testing.
* Delete or comment out this listen block on production servers
* and use TLS on port 6697 instead.
*/
Also throw it in translated example*conf's (in English),
the translators can translate it.
one could possibly miss this cert verification warning. And since
that will later become an error, it is even more important to
notice such a (hopefully unusual) case quickly.
On the incoming side it was correctly identified as link sec 2,
but on the outgoing side the localhost check failed and caused link sec 1 or 0.
Bug has beent here for a while but I don't think many people
link two UnrealIRCd servers over localhost that are on production
(i do, when dev'ing, but then I don't care about linksec, obviously)
Also, this wouldn't flag services from 2 to 0 because this bug only
affected outgoing UnrealIRCd server connections.
not verified. This changes the wording from "You may want to consider" to
a warning, makes it more strong and that in the future we will reject this
by default.
Actually still pondering to reject it now already by default, but let's start
with this commit first...
Is same as baseline.txt but with this line added:
+"FS_KEMs","127.0.0.1/127.0.0.1","5901","OK","X25519MLKEM768","",""
This so debian 13 test succeeds (and other future distros with OpenSSL 3.5+)
* [set::tls](https://www.unrealircd.org/docs/TLS_Ciphers_and_protocols):
Rename `ecdh-curves` to `groups` (the old name will continue to work)
* Add (and prefer) the `X25519MLKEM768` hybrid group, which is a mix
of `X25519` that is commonly used today and quantum-safe `ML-KEM-768`.
This to protect against
["harvest now, decrypt later"](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later).
* To benefit from this, OpenSSL 3.5.0 or later (released April 2025)
is required on the server, and similarly a client that supports this.
At the time of writing, almost all Linux distros don't have such an
OpenSSL version yet (which is not a problem, this new feature will simply
not be available). Notably Debian 13 (when released in August
2025) will have it. LibreSSL does not support it either yet, so our
Windows build does not have this feature.
* Also, change the TLS information on-connect and in WHOIS etc. from
something like `TLSv1.3-TLS_CHACHA20_POLY1305_SHA256` to
`TLSv1.3/X25519/TLS_CHACHA20_POLY1305_SHA256`. In other words: using
slashes as separators and showing the group / key exchange in the middle.
The group is only shown on newer OpenSSL versions. If someone would
use the new PQC hybrid group mentioned above then their TLS info would
start with `TLSv1.3/X25519MLKEM768/`.
* TL;DR: better secrecy against future quantum attacks, even though
not many clients or servers support it at the moment.
[skip ci]
Bram Matthys