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.
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.
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...
[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
* 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
This will return the number of characters that are in the unicode block
with that name.
spamfilter {
rule "unicode_count('Emoticons')>2";
target { private; channel; private-notice; channel-notice; }
action block;
reason "Too much emotion";
}
In this commit we also make it so we pass the ClientContext (including
clictx->textanalysis) in crule_context.
You will still get a score of +1 if afterwards changing back to Latin
or anything else, but at least the Latin/anything -> Emoticon
transition is free now (score 0). And if ending with an emoji it
also means a score 0 (as far as this is concerned).
Example output:
*** SPAMINFO ***
This will show the original text and the deconfused text which can be used in a spamfilter block with input-conversion deconfused;
Original spam text: ẔŽŽẐ𝞕ȤℤΖℨℨ𝒁𝓩ẒŹƵᏃŻẒŽℨŹ𝒵𝛧Ż𝝛𝛧ℨℤ𝜡Ƶ𝞕𝘡ŹẐ𝑍ẔẐẐΖ𝜡Ẕ𝜡Ẕ𝞕ꓜ𝚭ᏃẐẔ𝙕
Deconfused spam text: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
AntiMixedUTF8 points: 64
Number of Unicode characters in total: 50
Number of different Unicode blocks used: 8
Unicode Block breakdown (name: bytes [capped at 255]):
- Latin Extended-A: 8
- Latin Extended-B: 3
- Greek and Coptic: 2
- Cherokee: 2
- Latin Extended Additional: 12
- Letterlike Symbols: 6
- Lisu: 1
- Mathematical Alphanumeric Symbols: 16
In CommandAdd() the flag CMD_TEXTANALYSIS now means that the last
parameter of the command will run through the text analysis system.
This flag is set in PRIVMSG NOTICE PART QUIT AWAY SETNAME TOPIC
Make match_spamfilter use the clictx->textanalysis->deconfused rather than
calculating its own. The latter will probably disappear altogether.
Unrelated but also fixed: properly set e->unicode_blocks.
switches like antimixedutf8 did, and counts the number of characters
used per unicode block. Potentially more can be added later, this is
flexible and modules can add stuff (..well not yet.. the struct is
missing some members..).
Use it from antimixedutf8 so that it now uses the new code, which is
similar to what I made and then reverted in July 2023:
https://github.com/unrealircd/unrealircd/commit/3e2f668f10fccedfd035526d7b20d7ca6819a8ae
..except that it now calculated in src/modules/utf8functions.c.
But yeah, this needs more testing and possibly (default) score
adjustments to deal with false positives !! And a warning in release notes :D
Put the text analysis in ClientContext member textanalysis,
so typically accessed through clictx->textanalysis.
Note that this struct can (and often is) NULL, for example if it is
a remote client, if it is not a PRIVMSG/NOTICE (will improve later)
or if the utf8functions module is not loaded (to keep things optional).
BREAKING CHANGE is that ClientContext is now passed in the
HOOKTYPE_CAN_SEND_TO_CHANNEL and HOOKTYPE_CAN_SEND_TO_USER hooks.
So HOOKTYPE_CAN_SEND_TO_USER prototype changed from:
int hooktype_can_send_to_user(Client *client, Client *target, const char **text, const char **errmsg, SendType sendtype);
To:
int hooktype_can_send_to_user(Client *client, Client *target, const char **text, const char **errmsg, SendType sendtype, ClientContext *clictx);
And HOOKTYPE_CAN_SEND_TO_CHANNEL prototype changes from:
int hooktype_can_send_to_channel(Client *client, Channel *channel, Membership *member, const char **text, const char **errmsg, SendType sendtype);
To:
int hooktype_can_send_to_channel(Client *client, Channel *channel, Membership *member, const char **text, const char **errmsg, SendType sendtype, ClientContext *clictx);
A side-affect of this change for antimixedutf8 purposes is that,
while the analysis is only done once per line, the 'actions' are
performed for each target, so the action will run 4 times for
"PRIVMSG a,b,c,d :text" although that may not be important in
practice. Just mentioning.
generators/sources plus some manual tweaking.
This is not complete and not always correct. Sometimes there are
simple mistakes like ф -> f because that is a cyrillic f but it
should be seen as an o or something like that. Those still need to
be polished out. And some other things are just plain weird but
probably similar cases. In any case, with this commit things are
getting better. It will never be perfect or anything close to perfect
anyway!
I started work on this back then but didn't finalize it. Now I
have to figure out what was left to be done :D. Other than the
obvious case of seeing some debugging code that prints out for
every converted character. Not yet visible / usable by end-users!
Also fix documentation for ~10 hooks to mention the hook name.
Obviously, the maxperip module is loaded by default (in modules.default.conf)
but it is nice to have the 400+ lines contained in a separate module
rather than being in the nick module that does NICK/UID handling.
Will look at moving more later..
It now passes 'clictx' which at the moment only has clictx->cmd which
points to the command handler. So only useful in very few cases where
you have like a generic command handler and thus have no idea for which
command you are being called. In the future, with this new ClientContext
struct, we can simply add new fields to the struct without breaking
things in the core and in (third party) modules.
If you use the magic functions in your modules CMD_FUNC(cmd_mycmd),
OVERRIDE_FUNC(myoverride), CALL_NEXT_COMMAND_OVERRIDE() and such then
you shouldn't have any compile errors as these will use the correct
prototypes and variable names automatically. In a few cases you can't
use these, in which case you will need to update your modules.
Changed the log/snomask message from, for example:
Flood blocked (target-flood-user) from evil!xyz@localhost [127.0.0.1] to victim
To:
Flood blocked (target-flood-user) from evil!xyz@localhost [127.0.0.1] to victim (TAGMSG)
mostly with regards to memory leaks if duplicate config directives are used.
Eg using allow::password twice in the same allow block, or using
link::outgoing::tls-options twice in the same link block. Unusual stuff.
Previously if a new history item was added (because someone sent a message)
we would always append at the end of chat history buffer of the channel.
Now we put the message at the position decided by the "time" message tag,
which could be at the end but also slightly before that.
* Upside: should result in a consistent chat history on all servers
* Downside: if your server time is off for several seconds then it
could look a little weird. Then again, it would already have looked weird
in real live chat with timestamps and when replaying chat history probably.
Also add some simple optimizations: in the log line object we now have direct
pointers to the msgid and time strings, so the code doesn't need to do a
find_mtag() all the time. This should lower CPU usage during log playback
and also makes things more simple in the source code.
I did some testing with various history injection variants but this needs
more extensive testing.
because we send 9 character uids. However, IDLEN is defined as 12 so it is
natural for other people (services and other pseudo server writers) to assume
you could send 12, which failed until now, as it only accepted 11 characters.
Just to be clear:
* We generate and send 9 character uids in UnrealIRCd ourselves, this
works perfectly fine
* In 114d54ac61 in 2021 (UnrealIRCd 5.2.1) i
enlarged the buffers to allow INCOMING ids of up to 12 characters.
The reason for that is that I want the option to allow slightly larger
uids and could start doing that several years later without causing
desynchs and other problems.
* That didn't work properly, it only allowed up to 11 chars at this point.
* From now on it allows 12 chars. I do NOT recommend sending that though, if
you want to send bigger ids from your services/pseudo server then use
11, or... actually just use 9 like in normal unrealircd traffic at the
moment.
Reported on IRC by craftxbox
Bram Matthys