The snotice sent to other opers can be misleading. For example, it will say
host mismatch even if the host is correct but the username is wrong, or if
the oper name given does not exist in the configuration.
The snotice sent to other opers can be misleading. For example, it will say
host mismatch even if the host is correct but the username is wrong, or if
the oper name given does not exist in the configuration.
Fixes crash introduced by 0ab6dbbc65. It's
probably a regression since it defeats a system designed to stop this
from happening, but I didn't dig through the history.
rehash() closes listeners. If we happen to get a single epoll() result
that wants to first rehash and then accept a connection, the epoll info
will point to a freed rb_fde_t. Other selectors should have similar
problems, but we didn't investigate that.
rb_fde_ts are normally batched up and freed outside the event
processing, but as of the above commit close_listeners() screws that up
by closing pending FDs immediately in order to create new listeners.
I think it might be a bit better to revert this behaviour and simply not
close listeners if we are going to open new ones over them, but have
opted for the smallest reasonable change I can think of.
Helped-by: Eric Mertens <emertens@gmail.com>
This commit returns $x's old behavior as long as the mask does not
contain a #, otherwise it uses the new behavior that supports
CIDR notation.
This fixes `$x:*badword*` not matching realnames containing "badword".
This allows explicitly loading a module in the config so it's available
for later config items that might need it, and skips the double load
when main loads all modules, which would cause errors
If main is called more than once (like in tests), everything is
reinitialized except the loaded module list and module paths, so clear
them too so that modules are loaded again and the path list is correct.
This allows a channel operator to set a channel ban such as
"$x:*!*@192.0.2.0/24#*web.libera.chat*" and have it function
as intended.
Closessolanum-ircd/solanum#26
* Add extension extb_guest
This module provides an extban type that acts as a normal ban but
only matches unidentified users.
* Document extban g in help/opers/extban
* extensions/extb_guest: support CIDR masks in $g extbans
This allows a channel operator to set a channel ban such as
"$g:*!*@192.0.2.0/24#*web.libera.chat*" and have it function
as intended.
---------
Co-authored-by: Aaron Jones <me@aaronmdjones.net>
This way it increments for every change. It need not be a timestamp, as
its actual value is not important.
This fixes an issue where a ban could be set, hit, and cleared all in
the same second, and the affected client would still be cached as banned
because the bants hadn't actually changed.
Before splitting things out into hooks, umode +Rg would only notify the
recipient if the sender satisfied +R. This restores that behavior by
making the +g hook happen after +R.
authd child processes are only told about configured DNSBLs when the
configuration is being parsed.
This is bad, because when authd crashes or is killed, IRCd will restart
it, but will not tell it about any configured DNSBLs until IRCd is next
rehashed.
We already have a dictionary that stores configured DNSBLs (for hit
statistics for `STATS n'), so store the additional needed fields in
that structure, and loop over that dictionary's entries when authd is
restarted, sending the fields just as if the configuration were being
reloaded.
Reported-By: @Unit193
Ensure we deallocate the nodes created by the first loop, and zero out
the authd data after removing them from the authd clients dict.
The authd_abort_client() function already does the latter, so just call
that instead of authd_free_client().
If the user performing a WHOIS has hidden their idle time (is umode +I),
also prevent them from seeing other user's idle times, even if said users
are not themselves umode +I.
Suggested-by: @Unit193
This doesn't make sense in a world where post-registration SASL is
allowed, and should fix one case of an annoying login desync that's seen
in the real world.
Specifically, when a client sends its final AUTHENTICATE and Atheme
receives it, it sends an SVSLOGIN for that client. If the client sends
us its CAP END *before* we see the SVSLOGIN, the implicit abort will try
to abort the SASL session that's already succeeded.
Atheme interprets this as an instruction to forget about the successful
SASL session; you'll connect unidentified. But it's already sent
SVSLOGIN, which will log the client in ircd-side, causing ircd and
services views to differ until the user authenticates again manually.
I think allowing a SASL session to be aborted when it has already
succeeded is an Atheme bug, and it can still be triggered without this
change. But our behaviour here seems silly anyway.
