This should help gcc/clang with finding more OOB write bugs.
It does mean that 3rd party modules can no longer use the something like:
struct { char name[1]; }
and then alloc(sizeof(struct) + length of name)
instead the struct element needs to be name[];
...and they would need to alloc(sizeof(struct) + length of name + 1)
No 3rd party modules in unrealircd-contrib use this so.. hopefully fine.
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.
Previously, due to HARDEN_LDFLAGS missing in MODULEFLAGS we were
only partial RELRO instead of full RELRO. This is a defense-in-
depth measure but is good to have and the ommission was unintended.
the particular extended ban module if you don't want it.
For example, if you include the default modules.default.conf and, say,
you don't want ~quiet extbans then you add this in your unrealircd.conf:
blacklist-module "extbans/quiet";
instead of arbitrary 256 and such. Also makes it so other people
reading this code will understand better that MAXBANLEN is the
real limit here and not 256 (which is never reached because
the cut off already happens at 200).
This shouldn't be needed except for some corner cases, like if some
third party module does not limit their stuff properly, in S2S
or if channeldb contains some weird long entry or something.
allow bans of NICKLEN+USERLEN+HOSTLEN+3. Previously NICKLEN was
ommitted for some reason, which also explains why this ban-
simplification-routine exists in the first place. I think we can
make it use this full n!u@h space. Especially since we already allow
this for bans like ~quiet (the full n!u@h) and other extbans can be
quite long as well, it no longer makes sense to limit it here.
Small detail: in extban_conv_param_nuh() we used +32 which i think
is from the times when we had to deal with prefixes like ~quiet,
which is no longer the case, this routine is only about the final
suffix after the last : in a ban.
This would cause a bit of a mess, that usually would be resolved a few
seconds later, but still a mess. I had this on irc*.unrealircd.org
myself when rerouting a server from a backup-hub to primary-hub
a few months ago.
This is not an issue now in all code paths, but if someone accidentally uses
SupportXYZ() without checking IsServer() then it would be an issue.
In the past we used client->local->proto for client flags as well, but this
has been split off to client->local->caps a while ago.
I guess we should rename client->local->proto to something more server-ish
in a later major release to indicate this as well.
if (cmptr->flags != 0) { /* temporary until all commands are updated */
But that is impossible, as CommandAdd()->CommandAddInternal() already has:
if (!flags)
{
config_error("CommandAdd(): Could not add command '%s': flags are 0", cmd);
And this is the case since commit ceb04cc3eb
from July 15, 2015.
and callback data in non-DEBUGMODE. Also because exposing pointers like
this can defeat ASLR. These STATS are oper-only though, but hey, defense in
depth... and the pointer values don't make sense to non-devs anyway,
so why show them in the first place.
We use mtag_add_issued_by() to prepare it but then pass NULL
in do_cmd() so it was basically useless.
Also compile fix for previous (forgot to git ammend)
Every time compression has been used in TLS it has been a source of
trouble. We don't care about such optimizations anyway since connections
are long-lived in IRC. We are not some kind of webserver where every
millisecond counts.
This one has DNS caching enabled[*], which makes sense for this case.
[*] If using c-ares 1.31.0 or later. That version was released in June 2024.
The shipped-with-UnrealIRCd library version is 1.34.6, so qualifies.
However, if using system c-ares (which is automatically the case, if detected)
then many systems don't have it. The first Linux distro versions that qualify:
* Fedora 40
* Debian 13
* Ubuntu 25.04 (non-LTS) and future Ubuntu 26.04 (LTS)
* Etc...
Previously it showed this warning and said "Allowing user .. in unchecked"
when the user got shunend by CBL. Usually harmless but.. had a report
where it possibly was not (though that was an older UnrealIRCd version).
In any case, confusing, solved now!
This was a long standing requests by devs.
So if third/something is version 1.2.3 in the repository, and you have
src/modules/third/something.c which is version 1.2.4 then neither
'./unrealircd module upgrade' nor './unrealircd module upgrade third/something'
will overwrite the module. It will stay the local 1.2.4 version.
A new status inst/LOCAL was added "module installed, local version is newer
than available online"
The command './unrealircd install third/something' would still (re)install
the online version, though, i think that makes sense.
When working on this I noticed that './unrealircd module upgrade' previously
always recompiled the module, even if it was not updated. This is no longer so.
Reject it with an ERR_INVALIDMODEPARAM, just like we do for +k.
I think the higher number transforming is fine, but this <=0 transformation
is odd as it almost never is what the user actually intended.
In S2S traffic we still transform, as rejecting there is more problematic,
(causing a desync) and transforming it there is not a major issue, anyway.
Reported by ProgVal in https://bugs.unrealircd.org/view.php?id=6602
since the message/notice would not make it through either.
This also means someone can no longer iterate through users to see who
is +D/+R by sending a "silent" TAGMSG. (Silent in the sense that the
end-user usually would not have noticed)
Suggested in https://bugs.unrealircd.org/view.php?id=6579 by zw32h (I think)
This also means HOOKTYPE_CAN_SEND_TO_USER now allows you to NOT to
set errmsg, to silently drop a message. Previously we would crash
deliberately on such a situation to enforce that all modules would
set a proper errmsg.
(commit 0cf0c0faa2)
This was caused by register_user() being called twice, while it should
only have been called if !IsUser().
Reported by ProgVal in https://bugs.unrealircd.org/view.php?id=6606
My BuildBot screen was also all red :D.
Bram Matthys