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.
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
This code is doing (foo - (char*)0) to convert foo from a pointer
value into a numeric value. Unfortunately, this is undefined
behaviour, which clang-14 is now warning about [1].
Cast to uintptr_t instead. Same result, but well-defined.
[1] cf. commit 0302f1532b
The spaces surrounding the = is bad syntax, which causes the shell to try to
execute 'assert'.
Granted, all of this is just cosmetic, as the only use of $assert seems to be
in the echo at the end of the configure run.
Unlike Linux, Solaris, and Illumos (and probably others), the 2 BSDs that still
support SCTP didn't put SCTP into its own library, they put it into libc.
They, unlike Linux, don't set SOL_SCTP for us. The official method appears to
be calling getprotobyname("sctp") & endprotoent(), with getprotobyname()
returning a struct that has a p_proto entry. This all reads from
/etc/protocols. However, SCTP is assigned 132 by IANA, so it's 132 everywhere,
so I just set SOL_SCTP to 132 if it's not already set.
Due to [1], linking with SCTP sometimes does not multi-home correctly.
This is triggered by the rand() on the lines immediately above these.
The connect{} blocks already support an `aftype` parameter to instruct
IRCd to prefer IPv4 or IPv6. This commit additionally ensures that the
other structure is always populated with the other address (if any) if
this parameter is specified.
This will allow SCTP server-linking users to work around the bug and
ensure that it always multi-homes by setting `connect::aftype` to IPv4.
Without this commit, that would cause Solanum to not include the IPv6
addresses (if any) in the connect block in its SCTP setup.
If there isn't a valid IP address in the other sockaddr, this should be
of no consequence, because it will not be used by rb_connect_tcp(), and
both rb_connect_sctp() and rb_sctp_bindx_only() already verify that
there is a valid IP address in the sockaddr before making use of it.
[1] https://marc.info/?l=linux-sctp&m=165684809726472&w=2
