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
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.
Edited by @aaronmdjones:
- Correct some data types and casts
- Minor style fixups (e.g. we put * on the variable name not the type)
- librb/src/openssl.c:
- Defer call of BIO_free(3ssl) to the end of the conditional block
to avoid having calls to it in multiple paths
- Check the return value of SSL_CTX_set0_tmp_dh_pkey(3ssl) because if
it fails then we must use EVP_PKEY_free(3ssl) to avoid a memory leak
This could fail if, for example, the user supplied DSA parameters
in the DH parameters file instead.
- ircd/newconf.c:
- Check whether OSSL_DECODER_CTX_new_for_pkey(3ssl) was able to parse
the given CHALLANGE public key as a valid RSA public key, and then
check whether OSSL_DECODER_from_bio(3ssl) actually loads it
successfully
- ircd/s_newconf.c:
- Use EVP_PKEY_free(3ssl) instead of OPENSSL_free(3ssl) on EVP_PKEY
pointers; this will avoid inadvertent memory leaks if the EVP_PKEY
structure contains any dynamically-allocated child members
- modules/m_challenge.c:
- Unconditionally use EVP(3ssl) to generate the SHA-1 digest of the
random challenge; this API has been around for a very long time and
is available in all supported versions of OpenSSL
- Add lots of error checking to all steps of the process
Tested against 1.1.1 and 3.0; both with missing and provided DH parameters
(which works as you'd expect; the server will not negotiate a DHE cipher
without them), and CHALLENGE, including missing keys or keys of the wrong
type (e.g. when you supply an EdDSA key instead of an RSA key).
This does break compatibility with OpenSSL 1.1.0 and below, which are now
all end-of-life and unsupported anyway.
Closes#357
Loose port of 6ea60b2297948211925e22bd1f284179d680b4ae. I've chosen to
reduce indentation where it's convenient, and I'm allowing >-[0-9] as a
way of specifying a minimum of 0 because... I don't know, it just seems
neater to me.
* and ? are valid characters for channel names on IRC, and ELIST M gives
no way to distinguish between `LIST #foo-*` that's meant to search for
channels beginning `#foo-` and `LIST #foo-*` that's meant to list one
channel named literally `#foo-*`.
In order to deal with this, we will always assume a name with wildcards
is a mask. If it's also a channel name, that will be listed first.
Further to our implementation of the concept of "secure origins", we can
indicate to services that the client is connected securely, rather than
just that the client is using TLS. For example, connections from the
local host (from the IRCd's perspective) can be considered secure
against eavesdropping.
Allow this to factor into services' decision on whether to allow an SASL
negotiation or not. Atheme currently assumes this means the client is
using TLS, but I have changed that in atheme/atheme@412d50103c
