https://github.com/solanum-ircd/solanum https://cgit.space/~irc/github.com/solanum-ircd/solanum.git/atom/modules/m_challenge.c?h=amdj%2Fmodules 2023-11-06T14:47:16Z 2023-11-06T14:47:16Z Aaron Jones 2023-10-04T18:52:47Z urn:sha1:3b24363e9174d3c07c863ff39f794383f377101d 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. 2023-11-06T14:47:16Z Aaron Jones 2023-10-04T18:48:42Z urn:sha1:c790520218b6da02e1c633e1ed57b310efe53ff4 I suspect this is a copy/paste omission when duplicating the code from modules/m_oper.c when it was created. 2022-08-25T00:36:47Z jailbird777 2022-08-13T03:40:48Z urn:sha1:8e9a7418323a8cda056a04f5259e79aacba5229f 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 2020-11-19T21:48:44Z Doug Freed 2020-11-19T19:19:14Z urn:sha1:73520cd1ed67ae012c145f564ea4eb958e642d77 2020-11-18T14:29:08Z jess 2020-11-18T14:29:08Z urn:sha1:40ecb85a1d4f77b92bc4dd462add44cb8e4f3be1 2020-11-08T19:30:41Z jess 2020-11-08T19:30:41Z urn:sha1:a92275551218402bf4969a7fe613cab27416c4ef 2020-10-31T16:00:02Z Ed Kellett 2020-10-28T21:55:26Z urn:sha1:35eccf49306c5f774229a67b4966719c14444d0f 2019-09-13T09:08:27Z Ed Kellett 2019-07-07T01:36:58Z urn:sha1:ed3ca2ff16a1dc921d90c0a67093de8f47209176 Move opername and privset storage to struct User, so it can exist for remote opers. On /oper and when bursting opers, send: :foo OPER opername privset which sets foo's opername and privset. The contents of the privset on remote servers come from the remote server's config, so the potential for confusion exists if these do not match. If an oper's privset does not exist on a server that sees it, it will complain, but create a placeholder privset. If the privset is created by a rehash, this will be reflected properly. /privs is udpated to take an optional argument, the server to query, and is now local by default: /privs [[nick_or_server] nick] 2016-04-05T10:39:59Z Elizabeth Myers 2016-04-05T10:39:59Z urn:sha1:f956cb0f1f94923187804c772e099b9c8b9d76e5 2016-03-09T07:37:03Z Elizabeth Myers 2016-03-09T07:37:03Z urn:sha1:3c7d6fcce7a021ea7c4948a37a32aeca072e5b10 Also fix up some return values and stuff to use bool (or void if nothing). I just did it whilst I was here. According to jilles, the return value used to signify whether or not the client had exited. This was error-prone and was fixed a long, long time ago, but the return value was left int for historical reasons. Since the return type is not used (and has no clear use case anyway), it's safe to just get rid of it.