These were not a surprise, but deliberate: we let the previous
clang-format commit be 100% clang-format job (so reproducable)
and after that we planend and did this commit, because we chose
to leave some stuff alone and do it manually.
This commit will (also) be added to .git-blame-ignore-revs
This reformats entire UnrealIRCd source code, according to
.clang-format which was previously commited.
This is reproducable using clang-format version 21.1.8.
These are only visual changes, they have no effect on code.
This commit will be added to .git-blame-ignore-revs so 'git blame'
and the similar blame view on GitHub will ignore this commit.
* Add a trailing comma after the last element. Without it clang-format
glues the closing brace onto the last element, like "NULL};".
* Write '= {' on the declaration line instead of a lone '{' on the next
line. clang-format keeps such a lone '{' as-is but gives it and the
whole body an extra continuation indent, which looks weird.
Suggested by westid in https://bugs.unrealircd.org/view.php?id=6477
* New [crule function](https://www.unrealircd.org/docs/Crule) that return
the number of times a flood was blocked for that user. For example,
`server_flood_count('away')` returns the number of time away-flood
was exceeded. Aslo available: `nick`, `join`, `invite`, `knock`,
`vhost` and `conversations`. Plus, there is `all` for a total of all.
* This can be used in a security-group::rule or spamfilter::rule.
Eg: `spamfilter { rule "server_flood_count('nick')>4"; action gline; }`
This also - internally - adds a mechanism to run spamfilter rule-only-
filters after the command handler, whenever a tag value or other thing
changed. That's part of this commit.
and 7 for unknown-users (with max-bytes 5250 and 1500 respectively). This
allows pasting a short snippet of code, config file, text from a site, etc.
With multiline you have the guarantee that:
1) You will see the entire text with no delay between lines
2) You won't see another persons chat half-way through such a paste
3) For multiline supporting clients it is now clear that all the text
belongs to each other, which can make selecting/copying it easier.
This basically means short snippets/pastes like that can be completely on
IRC again. No need for a pastebin for it. Though, you may still need such
a service if you are pasting more lines.
Regarding the implementation in UnrealIRCd:
* Clients without multiline get individual fallback lines (concat lines
merged, blank lines skipped, as per spec). And we know that clients like
weechat - which does support multiline - also shows all lines and not
only a few plus snippet style "[.."]. That is another reason for only
allowing 15 lines by default and not something much more. Otherwise all
those clients would get a big wall of text, which just sucks.
* Spamfilter (also) runs on the full text of all lines together, so
splitting a phrase across lines does not evade spamfilter.
* Fakelag: a client can send the BATCH start+PRIVMSG (or NOTICE)+BATCH end
at full speed. We impose no fake lag there. Also, the multiline default
max-lines and max-bytes are lower than the example class::recvq of 8000,
so should be perfectly safe. If the entire BATCH is accepted then we
will impose fake-lag afterwards, with a cap of 15 seconds maximum.
If the BATCH is rejected, we impose half the fakelag plus 2sec.
* If the time between BATCH start and BATCH end is more than 15 seconds
then the BATCH is rejected (set::multiline::batch-timeout).
* The BATCH is atomic (either you see it all, or you see none of it):
* When the client sends it to server, it is buffered first.
* Only after the batch close the server indicates if it is accepted
or rejected. This has various reasons, two of them are: 1) The client
is going to send everything in one go anyway and not wait for a
response between each PRIVMSG, and 2) we can't do many checks in the
buffering stage and skip those after, that would cause a TOCTOU
problem (eg. a banned user still being able to speak).
* If any line gets rejected due to spamfilter or other case
(eg +c, +b ~text with block, etc etc), the entire batch is rejected
* Locally we deliver all or nothing (as said)
* S2S we buffer the batch as well, so if a server splits after having
received 10 lines out of 15, then clients will not see anything.
* We send max-lines and max-bytes, this is the hard upper limit.
* A multiline can still be limited more tight if:
* +f with 't' or 'm' restricts to fewer lines,
eg +f [5t]:15, which means max 5 lines per 15 seconds,
means the max accepted multiline is 5 for that channel.
* +F works the same, except that default +F normal does not
have a 't' at the moment and 'm' is very high (50) so
practically not limited by default.
* There will be a future +f flood subtype for some more control
TODO: we will send CAP NEW on unknown-users <-> known-users to
indicate the new max-lines value if you transition security groups
TODO: chat history does not yet include multiline batches.
in NameList, Tag, Watch and HistoryLogLine.
This does mean the allocation routines need a +1 everywhere, but
I think I got all of them. I also don't see them being used directly
in such a way in 3rd party modules (which is logical, as they
should use the API and not allocate such structs directly).
Also, SpamExcept has been removed as it was not used anywhere.
user is in known-users or in unknown-users. Not used anywhere yet.
Every 2 minutes we rescore all users. Or more specifically: every
5 seconds we rescore 1/24th of all users. That's the slow update path.
On certain events that cause a likely/possible transition, we update
the cache immediately. At the moment that is on IP change and account
login/logout. More will be added later.
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
This also automatically adds it as a security group and mask item:
ban user {
mask { asn 64496; }
reason "Testing ASN ban";
}
And yeah, it is a normal extban too (in +b and +I). Users usually
don't know the AS Number of other users, though, unless you change
the default configuration (at the cost of privacy).
Updated release notes a bit... more will follow.
when they are only in channel(s) with very low member counts.
This because some typical bot/drone behavior is not to join any channels.
This kinda forces them to expose themselves a bit more (and if they don't,
they don't get more reputation).
The downside is for the unusual case where a legit chatter would be on
the network but not joining any channels, but that is rare. In any case,
this setting can be adjusted if that is typical or more normal behavior
on your network :D.
* The [reputation score](https://www.unrealircd.org/docs/Reputation_score)
of connected users (actually IP's) is increased every 5 minutes. We still
do this, but only for users who are at least in one channel that has 3
or more members. This setting is tweakable via
[set::reputation::score-bump-timer-minimum-channel-members](https://www.unrealircd.org/docs/Set_block#set::reputation).
Setting this to 0 means to bump scores also for people who are in no
channels at all, which was the behavior in previous UnrealIRCd versions.
It is now possible to override some set settings per-security group by
having a set block with a name, like `set unknown-users { }`
* You could use this to set more limitations for unknown-users:
```
set unknown-users {
max-channels-per-user 5;
static-quit "Quit";
static-part yes;
}
```
* Or to set higher values (higher than the normal set block)
for trusted users:
```
security-group trusted-bots {
account { BotOne; BotTwo; }
}
set trusted-bots {
max-channels-per-user 25;
}
```
* Currently the following settings can be used in a set xxx { } block:
set::auto-join, set::modes-on-connect, set::restrict-usermodes,
set::max-channels-per-user, set::static-quit, set::static-part.
the default set::max-channels-per-user (also called set::maxchannelsperuser).
This way you can give known-users a higher max-channels-per-user,
or even a special security group for trusted users (that you may
already have given a more lax flood setting and lower lag-penalty
etc. etc. so that fits in nicely)
And yeah this also:
* Makes it both in set and the anti-flood block accept both
maxchannelsperuser and max-channels-per-user.
* Removes old MAXCHANNELS= in 005, as we already have CHANLIMIT=
This does not:
* Re-announce the 005 CHANLIMIT= if someone transitions from a security
group with a different max-channels-per-user. We don't do that for
IRCOps either, and I think no IRCd does that actually...
To be honest i wonder if sending the limit in 005 is useful at all,
do client really track this and limit their GUI based on it?? Doubt it!
for the add, like: nick-change, quit, server terminating. Add logon time.
I also think i will move from user.get_whowas to a whowas.XXX since the
returned object is not a user object and getting more different each commit :D.
but it seems there were still a couple left. These are now gone as well.
There seem to be no issues with the ones that were left, but it is just
too easy to get it wrong. Declaring buf in function now. This should be
faster anyway, since it is located on nearby memory (stack).
Inspired by previous find from westor (c708a99955c034e842f913479cc597d87b311394).
When someone is trying to connect and he/she is shunned , it will be displayed on connection server notice, yeah sometimes it might be helpful, why not..
Suggested by armyn https://bugs.unrealircd.org/view.php?id=6106
Pretty much everywhere we had:
0001 userhost_changed(client);
0002 if (MyUser(client))
0003 sendnumeric(client, RPL_HOSTHIDDEN, client->user->virthost);
Lines 2-3 are now integrated in userhost_changed().
Also fix two issues with CHGHOST in make_oper():
* if user was -x, modes had +x and a vhost, it would send the cloaked
host in the original vhost, while it should have been the real host
* if user was -x and went +x without vhost (so only uncloaked to cloaked)
then no CHGHOST message was sent at all
The extban module API is used behind the scenes. To the server admin
the functionality appears in a more natural way:
account { <list>; };
country { <list>; };
realname { <list>; };
certfp { <list>; };
In the same way, they appear as exclude-xxx options too:
exclude-account { <list>; };
exclude-country { <list>; };
exclude-realname { <list>; };
exclude-certfp { <list>; };
Modules can add additional fields (3rd party modules too!).
Module coders:
See src/modules/extbans/realname.c for a simple example. In short:
1) You need to register your extban in both MOD_TEST and MOD_INIT
2) Other than that, the existing rules for extended server bans apply:
a) Your req.is_banned_events needs to include BANCHK_TKL
b) Your req.options needs to include EXTBOPT_TKL
Be advised that for modules that are called in extended server bans
the client may be missing several fields, for example client->user could
be NULL, so be careful with accessing everything in your module.
security-group { mask ~security-group:xyz; }
Module coders (again, slightly unrelated):
Added unreal_add_names() function which can be used to transform
a list of names in the config to a linked list (NameList).
security group that references another (or itself), eg:
security-group abc {
include-mask ~security-group:abc;
}
We now give up after a recursion depth of >8 and log a warning.
been connected to IRC. See https://www.unrealircd.org/docs/Security-group_block
Slightly unrelated, for modules coders: new function get_connected_time(),
to see how long a client has been online. This works for local clients, in
which case it would just return TStime()-client->local->creationtime.
It also works for remote clients, for which it will use the newly added
"creationtime" moddata (commit f1a18ce37e),
so the info is only available for remote clients on newer servers.
If the info cannot be found it will return 0 (zero).
It means you can no longer modify eg parv[1] in-place with strtoken and such.
The main reason for this is that as a command handler you have no idea
where the arguments may come from. It could be from a do_cmd() with
read-only storage (eg a string literal) and so on.
It started with an experiment of how far I could get and how annoying the
side-effects would be, but they seem to be quite managable, so I'm
committing this stuff.
Hopefully this catches/solves some stupid bugs somewhere :)
Bram Matthys