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().
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
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
the logic for trying to detect the maximum value of time_t was broken;
since we target a lower maximum time anyway, just use that for the
overflow check
While working on reproducible builds for openSUSE, I found that
our package varied even when building in clean VMs
with as little non-determinism as possible.
This was because of
+++ solanum-0~ch560/ircd/version.c.last
@@ -25,7 +25,7 @@
#include "serno.h"
#include "stdinc.h"
-const char *generation = "6";
+const char *generation = "5";
const char *creation = "1653004800";
const char *ircd_version = PATCHLEVEL;
const char *serno = SERNO;
I think this was always pretty questionable. You can set redundant bans
in various ways anyway, and preventing all of them would only make the
situation worse, as wide temporary bans would destroy narrow permanent
ones, for example.
Also, ignore a connect block that requests certfp authentication
without setting the ssl flag, as it will then go on to fail anyway.
Finally, correct an erroneous error message about class blocks.
