instead of the server executing the MODE. Eg unrealircd.org/userhost
was set. This occured because the client = &me; was done after
the message tag preparation, now moved up so it's done before.
for this amount of seconds (default: 75) when a server splits.
This helps in case a server dies and the clients reconnect to the
other servers, causing a join-flood to be triggered needlessly.
Of course, OTOH disabling a flood protection temporarily is not
ideal, but after seeing it being triggered too often and requiring
manual intervention in many +f/+F channels, this is the best option
I think, if we want +f/+F to work as painless as possible.
If you have a large network (eg: >5 servers) with equal user
spreading then you could disable this by setting it to 0, since then
1 server dieing may not have enough impact on +f join floods
for this to be needed.
TODO: Documentation and release notes
This is an integer which decides the amount of details in the response object.
See https://www.unrealircd.org/docs/JSON-RPC:User#Structure_of_a_client_object
Especially for user.list it can be a good idea to ask for less detail if
you don't need all the information. It's up to you...
When 'object_detail_level' is not specified in the request, then:
* For user.list it defaults to 2, which is a "breaking change" in the sense
that it leaves out the "channels" field. To see the "channels" field you
would have to use level 4.
* For user.get it defaults to 4, which results in the same output as 6.0.7.
* This makes sense so user.list is shorter than user.get, just like we
already did in channel.list and channel.get.
By the way, this is all documented in the API calls at
https://www.unrealircd.org/docs/JSON-RPC:User
and for channels at https://www.unrealircd.org/docs/JSON-RPC:Channel
This also changes the Detail level (object_detail_level) for the channel.* calls.
See https://www.unrealircd.org/docs/JSON-RPC:Channel_Object for latest info.
In short: at level 5, we now still hide the members.user.channels because
in general that object is not useful. When you do a channel.* API call
you want a list of users in the channel, and don't really care about
what other channels the user is in, other than the channel you already know.
This is an integer which decides the amount of details in the response object.
For the channel.* calls the object_detail_level is one of:
0: only return the channel name, nothing else
1: basic channel information only
2: this adds bans, ban_exemptions, invite_exceptions
3: also show members, but only level/name/id
4: also show members, level/name/id/hostname/ip/details/geoip
5: also show members, level and full user details like user.get
When no object_detail_level is specified, the following defaults are used:
For channel.list the default is 1 (matches current 6.0.6 behavior)
For channel.get the default is 3 (matches current 6.0.6 behavior)
Using channel.list with object_detail_level=5 is forbidden because
it would cause way too much output (and processing time).
Actually it accepts the following variations for this query:
MODE #test f
MODE #test +f
MODE #test F
MODE #test +F
As long as it is like that (with no parameter) we will show details.
Details are shown for all of the four possible combinations of having
or not having +f and +F.
For example "+F normal" and "+f [1k,20t]:10" result in this output:
Channel '#test' uses flood profile 'normal', without action(s) 'k' as they are overridden by +f.
Effective flood setting via +F: '[7c#C15,30j#R10,40m#M10,10n#N15]:15'
Plus flood setting via +f: '[1k,20t]:10'
-
List of available flood profiles for +F:
none: []:0
very-relaxed: [7c#C15,60j#R10,10k#K15,90m#M10,10n#N15]:15
relaxed: [7c#C15,45j#R10,10k#K15,60m#M10,10n#N15]:15
normal: [7c#C15,30j#R10,10k#K15,40m#M10,10n#N15]:15
strict: [7c#C15,15j#R10,10k#K15,40m#M10,10n#N15]:15
very-strict: [7c#C15,10j#R10,10k#K15,30m#M10,10n#N15]:15
See also https://www.unrealircd.org/docs/Channel_anti-flood_settings
When a channel CTCP flood happens and there is an +f with the 'c' floodtype,
we set channel mode +C by default. Alternative action possiblities
were +m and +M. I don't think anyone really used those alt actions for CTCP
because makes little sense to set the channel +m/+M on a CTCP flood when
there is +C which has far less impact.
More important, the fact that +m/+M could be set both upon CTCP flood
and upon message flood, this 'dual timer' thing, makes it rather
complex when we now have both +f and +F, so easiest solution is just
to scratch this possibility :)
if the join flood is caused by >75% of "unknown-users". This
to see if that will take care of the flood without harming
the "known-users" group. And naturally, do something similar
for message floods and nick floods.
If the flood persists, because they are caused by known-users,
then the +i/+m/etc actions are still taken.
This is work in progress, and some things are set to useful-
for-testing values, such as an unsettime of 1 minute.
for OpenSSL 1.0.2 anymore, 1.0.2 will use the fallback version.
This changes the include file.
(OpenSSL 1.0.2 is out of support since Jan 1 2020 so one may wonder
why care at all, but i'm trying not to break that during minor
UnrealIRCd releases)
the realhost/IP is communicated on a separate line. This so you now
can see both vhost/cloakedhost and realhost as an IRCOp in a single
WHOWAS request.
This also adds the MAXLINELENGTH define which is set to 4K+4K+512,
it can be used when you are dealing with complete lines (quite rare
in the code, mostly in socket code and labeled response).
And now also #define READBUFSIZE MAXLINELENGTH
but it is used beyond read buffers, als in write buffers of course.
Actually make them both use this same function, even thought he original
vhost::vhost check was a bit more informational.
This also checks the vhost in other paths that lead to oper vhost setting.
Reported by ji in https://bugs.unrealircd.org/view.php?id=5910
This was a counting bug in src/socket.c. The socket itself was actually
freed though, so it's purely counting that was wrong.
There could still be counting bugs elsewhere, it's always hard to get
this right, for 20 years already :D
This was previously tried at 19-apr-2020 in bc70882bd3
in UnrealIRCd 5.0.5. Sadly it had to be reverted immediately with a quick 5.0.5.1
release, all because of a PCRE2 100% CPU usage. Since then that bug has been fixed,
plus another bug. I'm now readding it "as an option" that is marked experimental.
Hopefully people test it out and can report back if it works well and then we can
make it the default someday.
This makes it a runtime setting so makes it much easier to switch back/forth if
there are any issues without recompiling anything. Had to use a bit more code now
though to handle the recompiling of spamfilters if the setting is changed.
Original issue was https://bugs.unrealircd.org/view.php?id=5187
* [Spamfilter](https://www.unrealircd.org/docs/Spamfilter) can be made UTF8-aware.
* This is experimental, to enable: `set { spamfilter { utf8 yes; } }``
* Case insensitive matches will then work better. For example, with extended
Latin, a spamfilter on `ę` then also matches `Ę`.
* Other PCRE2 features such as [\p](https://www.pcre.org/current/doc/html/pcre2syntax.html#SEC5)
can then be used. For example you can then set a spamfilter with the regex
`\p{Arabic}` to block all Arabic script.
Please do use these new tools with care. Blocking an entire language
or script is quite a drastic measure.
* As a consequence of this we require PCRE2 10.36 or newer. If your system
PCRE2 is older than this will mean the UnrealIRCd-shipped-library version
will be compiled and `./Config` may take a little longer than usual.
Reported by westor in https://bugs.unrealircd.org/view.php?id=6104
The code was there but the order of which the checks were done was
wrong, so first it was checking which CAP's were unloaded and after
that it was unloading the CAP, instead of the other way around.
Also renamed the function to clicap_check_for_changes()
to be consistent with other runtime change detection functions
like extcmodes_check_for_changes(), umodes_check_for_changes()
and charsys_check_for_changes().
entries that have the tag "oper", IOTW: the ones that are added
through the oper { } block, and not the ones added through
different means like a vhost { } block.
Really minor thingy but suggested by JanisB in
https://bugs.unrealircd.org/view.php?id=4233 and actually
possible nowadays when swhois items are tagged.
Hint: if you use SVSO to make someone oper, and then add swhois
entries, be sure to tag them with a setby of "oper" too, that
way they are hidden in +H and also automatically removed from
the user when the user does "MODE nick -o" to de-oper.
if you do actually have 1 snomask configured (a single one).
Although this is rather rare and unusual, it should be possible.
Previously we required at least 2 snomasks and the counter
did not properly reset during rehashes. Not sure why we required
2 and not 1, and the counter reset was a bug.
Reported by westor in https://bugs.unrealircd.org/view.php?id=5994
Reported in https://bugs.unrealircd.org/view.php?id=6100
Actually this only works if you have a:
blacklist-module geoip_classic;
in your conf and that conf is read before modules.default.conf
This is true if you have that blacklist-module line in your
unrealircd.conf, so should cover most cases.
Bram Matthys