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.
Set known_users=NULL during a very limited period, just to be safe.
(Note that it can also be NULL during initial boot, which is a
longer period, which is why we always NULL-check in the code that
accesses it, but this aside)
threshold.
* Possible transition to known-users:
* - logged in is already handled by HOOKTYPE_ACCOUNT_LOGIN so we don't care about those
* - score reached (or just over) the minimum reputation score
* Caveat: if having multiple connections from the same IP then
* the first one may theoretically not have crossed in some cases.
* Ah well, it is a cache, not some precise thingy.
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.
or elsewhere. I don't think this is an actual problem, but at least the
fix from 1abf73309a was inconsistent,
if we check for b->client further down, then we should not be reading
from it a few lines up. As said, don't think this code is reached in
practice, but hey...
thus removing commands that are only supposed to be used by IRC clients.
We don't intend to document things like CAP, PONG, etc here.
Remove ISON, PONG, WATCH. Also remove DALINFO which no longer exists.
Re-index the USERCMDS and OPERCMDS table. This removes no longer existing
commands and may also have added some that were not in the index.
Moved STATS from USERCMDS to OPERCMDS since by default it is Oper-only
(and very likely is so effectively in practice).
Maybe PRIVMSG is a bit inconsistent in all this, since users don't type
that but usually it is like MSG. But yeah.. okay.. i can live with that.
As an aside, I don't like services commands being documented in HELPOP,
but that is another matter. These should be 100% documented in the wiki
first before they are scratched in the HELPOP. Right now some are still
missing.
the config file, without having to resort to things like mask %~asn:XXX;
Now you can just use:
ban user {
asn { 11111; 22222; 33333; 44444; }
soft yes;
reason "This ASN is not allowed. If you have an account you can still bypass";
}
Requested by nobody but sounds like a good idea :)
Previously these showed up as "name":"<match item>", now they show
up properly like this:
"match": {
"account": "Syzop"
},
(... and have no "name" item)
Also expand spamfilter::except while we are at it.
* I changed "state":"active" to "state":"monitoring" to make clear it is
not throttling at that moment but actively monitoring the situation.
* The config::except stuff was previously shown directly under config
and only 3 particular items (that are most popular). Now we expand to
sub-item "except" and use json_expand_security_group() to expand all
the mask items, in a consistent way, just like for security groups.
{
"jsonrpc": "2.0",
"method": "connthrottle.status",
"id": 123,
"result": {
"enabled": true,
"throttling_this_minute": false,
"throttling_previous_minute": false,
"state": "monitoring",
"start_delay_remaining": 0,
"reputation_gathering": false,
"counters": {
"local_count": 0,
"global_count": 0
},
"stats_last_minute": {
"rejected_clients": 0,
"allowed_except": 0,
"allowed_unknown_users": 0
},
"config": {
"local_throttle_count": 20,
"local_throttle_period": 60,
"global_throttle_count": 30,
"global_throttle_period": 60,
"start_delay": 180,
"except": {
"identified": true,
"reputation_score": 24
}
}
}
}
* Add some missing fields, such as destination, but mostly in the
exclude- area where a bunch were missing (some of those are a bit
far fetched, but hey, they exist, so should be shown if in use).
* Re-order fields to more closely match the struct (still not 100%)
* Extended fields, such as "account" and "country", now show up
directly under the security group, just like the other fields,
such as "reputation_score". This is also how they show up in the
config file, so hide the the fact that internally in the struct it
is stored differently.
* Add a comment in SecurityGroup struct in include/struct.h to make
it clear you have to add/update stuff at 7 places if you are adding
something new.
Bram Matthys