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]
Previously this was like:
TLSv1.3-TLS_CHACHA20_POLY1305_SHA256
It is now changed to be like:
TLSv1.3/X25519/TLS_CHACHA20_POLY1305_SHA256
So:
* Changed from '-' to '/' because sometimes the cipher(suite)
contains a hyphen (TLSv1.2 and earlier)
* Show the key exchange "group" in the middle, such as X25519
for the usual non-PQC case and X25519MLKEM768 for hybrid group
with PQC.
* The group is shown in OpenSSL 3.0.0+ (and obviously you need
OpenSSL 3.5.0 to ever see X25519MLKEM768 there, but that is
something different)
[Channel flood protection by default](https://www.unrealircd.org/docs/Channel_anti-flood_settings):
This is an important change that IRCOps and chanops should know about:
* By default we now apply the anti-flood profile "normal", which should be fine for most channels.
* If a chanop does not want this they can override this by setting
`MODE +F` with [another profile](https://www.unrealircd.org/docs/Channel_anti-flood_settings#Channel_mode_F_profiles).
* For example, for a channel with hundreds of users and lots of activity
`+F relaxed` may be more appropriate. Or, chanops can turn anti-flood
off entirely by setting `+F off`
* The reason for this change is that many admins and chanops in practice
don't seem to use `+f` or `+F`. With this change they are now protected "by default"
when no MODE `+f` or `+F` is set.
* Advanced users can can grab the detailed effective settings with `MODE #test F`
(there will be an error if you use `cloak_md5`, but everything
will work fine if you use `cloak_sha256`).
We phased out MD5 usage years ago, so it is only contained to
the old cloaking module. In fact that was the only reason we
started to provide the SHA256 cloaking module, simply so it
isn't using old MD5.
Of course, for module coders this means they should not call
DoMD5() or md5hash(), but that would be rare. Currently zero
modules in unrealircd contrib do this and it makes no sense
to start using it nowadays anyway.
Since UnrealIRCd 6.0.0 when a server connects, we like to drop the
existing link so they don't need to wait on "Ping timeout".
However, that goes against the JUPE stuff that Services tend to use,
it basically negates it.
We now check if the uplink is u-lined (like for services) and if that
is the case we deny the link with "Server Exists (Juped)". So just
like before U6, and with a slightly more helpful message even.
Reported by Jellis in https://bugs.unrealircd.org/view.php?id=6498
We now expire after 30d if score is <12 (so 1 hour of being online)
and we expire after 90d regardless of score.
Note that for this to work, all servers would need to be running
UnrealIRCd 6.2.0+ because when a score for an IP is still present
on any of the servers on a network, and a user with that IP connects,
then the score will be broadcasted from the server that still has
the score and it will be re-added by all servers with that score.
But eventually it should be like this... :D
Reported by armyn in https://bugs.unrealircd.org/view.php?id=6536
are not (always) affected by this. We now check if there is any client port
exposed (to non-localhost). So if you have a hub with no client ports or
only at localhost then you won't get this bestpractices advice.
And also fix compile error on OpenSSL < 1.1.0 (undeclared var, duh)
suggest to use Let's Encrypt.
This can be turned off via set::best-practices::trusted-cert, see
https://www.unrealircd.org/docs/Set_block#set::best-practices
Oh yeah, and this only works at OpenSSL 1.1.0 and higher, i didn't bother
with people running ancient versions.
I totally agree with the goal to have this enabled, but let's do some more
testing with more clients first to see if they misbehave. Last thing I want
is a similar situation to when we were the first IRCd that sent "CAP DEL sasl"
and "CAP NEW sasl" when services went offline and online and it caused all
mIRC clients to reconnect. I don't expect this one to be so bad (also because
users would get the 005's when they typed /VERSION) but... let's test to be sure.
Should probably deploy this with enabled on irc.unrealircd.org and such :)
This re-sends these ISUPPORT tokens to let users know about important changes that may affect their display, most notably `PREFIX` can be problematic; for example if you have a server running and wish to load a module like ojoin or something else that relies on the client knowing the correlation between the mode and the prefix char, and without it the client just doesn't display the nicklist properly from then on until the client reconnects, which as we know can be a while until that happens.
The expected client reaction to duplicate ISUPPORT tokens according to the spec is to overwrite the current values. I have tested this in mIRC only and it works as expected.
* Calling from source is now in a separate function: int can_use_nick(Client *client, const char *nick)
* For hooks: don't free the reject reason, must use static storage like all other hooks
(TODO: clarify in all hooks?)
* Move it up a bit, right before find_qline
TODO (not necessarily me :D):
* Make it an efunc
* Also call it from some other places that do find_qline, like rpc/user.c
* You may want to prod 3rd party modules like SANICK
Bram Matthys