because it has no internet access, like when fetching the repository
(modules.list file) of 3rd party modules.
Previously I had..
url_start_async(request);
synchronous_http_request_in_progress = 1;
.. which worked fine for the "cannot connect case", like port blocked
or timeout connecting. But if DNS fails then the step of setting
synchronous_http_request_in_progress = -1 (so failed) already happens
during the url_start_async(request); call, and then the line after it
sets 'synchronous_http_request_in_progress = 1;' so we miss that it
failed and wait in the I/O loop forever.
Simply swapping the two lines of code fixes this.
The other change is that when running the ModuleManager in "make" we should
ignore the exit code. I probably broke that while refactoring and adding
non-zero exit codes in de modulemanager past few months for this release.
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.
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.
1) We now always look at the module { } block even for unmanaged modules
(so .c files that you put manually in src/modules/third)
2) New module::compile-flags to allow specifying compile flags / libraries / etc.
See https://www.unrealircd.org/docs/Special_module_manager_block_in_source_file
So the new stuff is:
module {
.....
// Simple library dependency:
compile-flags "-lsomelib";
// Can even use:
compile-flags "$(mysql_config --cflags) $(mysql_config --libs)";
.....
}
This was requested long ago by various people.
And yes, this allows shell commands to be executed if the 3rd party indicates so.
The added risk should be small, since the module could do similarly evil stuff at
runtime, unless you compile with a totally different user compared to runtime.
The most common case where compile time vs runtime is completely different would
be for packaging (deb/rpm/whatever), which presumably ship with zero 3rd party
modules, so then there shouldn't be a concern either.
Obviously, for 3rd party modules in the unrealircd-contrib repository we screen
modules to make sure they don't do anything evil: "No malicious code or intent"
in https://www.unrealircd.org/docs/Rules_for_3rd_party_modules_in_unrealircd-contrib
This gets rid of src/buildmod and unifies the process a little, which
i need later.
We still compile the 3rd party modules unconditionally and twice (during
both make and make install). Which is a quirk that is in there since U6
and maybe U5 already :D. That's because we don't check if header files
have changed. There was previously a "is the .c file newer than the .so"
in there, though, that is gone now. Anyway, that's something for later.
Another quirk is that we do not halt compile if a 3rd party module fails
to compile. Which was sortof intentional at one point but.. is not ideal,
so will probably changed as well.
Anyway, that's not why i am doing all this stuff right now...
This is to guard against clients that do like CAP LS 302, NICK, USER,
AUTHENTICATE, CAP END, without waiting for the SASL result.
Previously "CAP END" would abort SASL if the response was not in yet.
Now "CAP END" will cause us to wait for SASL success/fail/timeout
and when that happens we will end the handshake and the user will
come online (or not, if e.g. banned).
In other words, SASL is no longer canceled upon premature CAP END.
And yeah, clients should wait, as is mentioned in
https://ircv3.net/specs/extensions/sasl-3.1
"it is RECOMMENDED to only send CAP END when the SASL exchange is
completed or needs to be aborted"
But since it is a recommendation and not a hard requirement, we'll
be nice and handle this situation server-side.
Of course, clients could still misbehave then by sending stuff
blindly after CAP END, like JOIN events, without even checking
if they got numeric 001 and so on... so in that sense it shifts
the problem a bit.. but.. at least that type of waiting is
hopefully more common :D
Int32x32To64 macro internally truncates the arguments to int32,
while time_t is 64-bit on most/all modern platforms.
Therefore, usage of this macro creates a Year 2038 bug.
Bram Matthys