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.
Reported by 9pfs in https://bugs.unrealircd.org/view.php?id=6248
This is completely untested (other than ./unrealircd start), so
feedback from people who actually use crule like in deny link { }
is very much welcomed.
due to flood attacks, back then we changed the argument silently to
point to our own server, eg 'INFO some.remote.server' ended up being
'INFO' (local server) when requested by non-IRCOps.
Now, we simply return "Permission denied" in such cases, which is
more clear and explicit.
Reported by progval in https://bugs.unrealircd.org/view.php?id=6004
Reported by westor in https://bugs.unrealircd.org/view.php?id=6122
This because is_module_loaded() returned the 'current state' rather than
the 'future state', as mentioned in is_module_loaded() in a comment there.
Fix was swappping two lines.
Thanks to Noisytoot for https://github.com/unrealircd/unrealircd/pull/227
who suggested displaying account and provided a partial patch, and
armyn in https://bugs.unrealircd.org/view.php?id=6153 suggesting IP.
I chose to use the existing RPL_WHOIS* numerics that we also use for
returning WHOIS data. We already use RPL_WHOISSERVER in WHOWAS for
ages and the use of it is mentioned in RFC1459, so seems like that
was the idea right from the beginning of times. The only change I did
was from "is" to "was" in like "was logged in" and "was connecting from"
in the text of the numerics.
and other systems where 'make' was not GNU Make.
It now uses the same detection mechanism as in ./Config, which
should be known to work.
Reported by Valware and rj1 in https://bugs.unrealircd.org/view.php?id=6195
during MOD_INIT, while an IRCOp is listening. Or any log call, really.
This causes the code path: config_warn() -> do_unreal_log_opers() -[..]->
sendto_one() -[..]-> client_accepts_tag() for a client tag handler that is
no longer loaded.
The fix is to unload very late and load very early, a trick
we did earlier with websockets as well (c3824ad47d).
This so users can come online directly with the correct vhost set,
and not first with a standard (usually cloaked) host while auto-(re-)joining
followed by a CHGHOST later.
This is a long outstanding wish from users, I think.
Services can simply send a CHGHOST/CHGIDENT to the UID, for example
right before they send the SASL ... D S message (SASL succeeded)
they can send like: CHGHOST 002ABCDEF some.nice.host
Then UnrealIRCd 6.0.7-git and later will handle the CHGHOST even if
the user is not known yet. Technically, the server where the UID is
on will handle the message. And remote servers that don't know the
user with this UID yet will forward to the server with the SID-portion
of the UID. The CHGHOST will not be a broadcast but the vhost will
show up in the UID protocol message that introduces the user.
For CHGIDENT it is a similar story.
Light testing has been done but more extensive testing is welcomed.
Not sure if this is the best name, maybe I come up with a better one later.
The purpose of this function is so we can deliver certain messages to
pre-auth users, that is: users that are not fully registered yet.
This would mostly be used (perhaps exclusively) in SASL stage.
This is checked for both local and remote services linking in.
Naturally, the list can be expanded to include more services that
really need ulines { }, and not statistical services or some other
purpose non-unrealircd servers, which is the reason why cannot
blindly assume all non-unrealircd servers require ulines.
This should hopefully help users a lot with "mysterious" issues
with services that we see too often in the support channel.
Suggested in https://bugs.unrealircd.org/view.php?id=5742
Note that this does require services to communicate their software
version via EAUTH. Anope does this for years already, but atheme only
does so since 10 days ago (git only, presumably not released yet)
after Valware filed a PR.
This ensures that strings are of maximum 510 characters in length
and do not contain \n or \r.
Solves a lot of theoretical problems in many modules that .add
things or do other non-list/non-get actions.
This behavior can be turned off per-method (per handler) by setting
handler->flags = RPC_HANDLER_FLAGS_UNFILTERED;
This is currently not done in any of the modules.
Bram Matthys