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
