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.
certificate or key. It added the cert/key to the list of certs, like a
"dual cert" approach.
This was caused by commit 877d151da4,
which indeed adds support for "dual cert" (or more).
I have now deferred setting the default to happen only if no
set::tls::certificate is specified, as you would expect.
We (already) used a similar delayed-initialization / deferred setting
approach in the ::tls-options inheritance code (for blocks like
listen, sni, link, etc.)
Just as a slightly related reminder, we do normally suggest keeping the
conf/tls/server.cert.pem and conf/tls/server.key.pem for server linking
and then use a cert from a trusted CA in the listen block for 6697 etc.
See https://www.unrealircd.org/docs/Using_Let's_Encrypt_with_UnrealIRCd
for more information (and the 'why').
New RPC methods:
- security_group.list: List all security groups
- security_group.get: Get details of a specific security group
- connthrottle.status: Get full connection throttle status, counters, and config
- connthrottle.set: Enable/disable connection throttling
- connthrottle.reset: Reset connection throttling counts
This also adds json_expand_mask_list(), json_expand_name_list(), and
json_expand_nvplist() to src/json.c for reuse by RPC modules.
A link to https://www.unrealircd.org/docs/JSON-RPC and such is nice.
And also explain that not all JSON-RPC modules will be in rpc/*.
Sometimes it makes more sense to just put everything in the same
module, such as connthrottle RPC stuff in the connthrottle module.
It should be perfectly fine if you choose not to load these modules but,
while optimizing / speeding up the find_user_mode() function, i made
it crash in case the hunted user mode does not exist. Oops.
We still propagate in a non-biglines way, no plan to change that atm.
This is just future-proofing. More testing/auditing needs to be done,
especially to see if buffers are sufficient.
delayjoin was setting +d if there are invisible users still,
but it should only do that if the channel was +D earlier and
not in all cases (like if some other module is dealing with
invisible users).
* We try to keep the dynconf variables the same name as in the conf
(well, with hyphens to underscores, and there are some exceptions)
* Remove unnecessary but otherwise harmless second safe_free()
* The URL could have been too long. It is now limited to 360 characters,
which should be plenty.
throw an error (JSON_RPC_ERROR_USERNOTINCHANNEL) if this is not the case.
Previously we returned success.
Also, if using DEBUGMODE (never on production servers), the server
would crash if the user is not in the channel.
Bram Matthys