Sodium is a more modern alternative to OpenSSL and mcrypt, designed from the start to be resistant to timing attacks, and included in PHP 7.2 by default (while OpenSSL and mcrypt are separate modules). We should make sure MediaWiki makes use of it when it is available and OpenSSL is not.
and possibly other things?
At a quick grep, other uses of OpenSSL functions include:
I haven't checked whether the specific features used are also present in Sodium.
Also I see ConfirmEdit (CAPTCHA extension) has ./ReCaptcha/includes/recaptchalib.php which only uses mcrypt, but I don't see any code path that actually calls the mcrypt-using function.
a more modern alternative
Meaning "more recently written"?
We should probably support Sodium there, keeping in mind that depending on what algorithm was chosen, it might not be backwards-compatible (so we need to keep supporting OpenSSL). But passwords already have a type registry mechanism so it will be easy to deal with that.
- MediaWiki-extensions-OAuth in various places for RSA private key handling and signing.
Sodium does not support RSA; in general it does not necessarily try to be backwards compatible with OpenSSL, it tries to provide a superior set of crypto primitives for the same use cases (in the case of public-key encryption, X25519 + XSalsa20 + Poly1305). We probably don't want to deal with supporting multiple incompatible methods for the same purpose and then invalidating keys when the site switches encryption libraries, given that RSA keys are not used much in the first place and the security benefits compared to HMAC are fairly small; it's easier to just disable the RSA option when OpenSSL is not available.
- The CheckUserEncryptedData class in CheckUser.
That uses RC4. It's only needed for storing the text of emails sent via Special:EmailUser - does anyone even use that feature? (Wikimedia doesn't.) Same considerations apply: OpenSSL will be needed for B/C with already stored secret data (unless we add some kind of migration step), given that probably no one uses the feature, unlikely to be worth the effort.
- The sealing code in OATHAuthUtils in MediaWiki-extensions-OATHAuth.
That whole thing can be axed now that Session provides encryption directly (OATHAuth claims to be compatible with MediaWiki 1.27+ and session encryption was added to core in 1.2
- There's also reference from the TwitterLogin extension.
Also I see ConfirmEdit (CAPTCHA extension) has ./ReCaptcha/includes/recaptchalib.php which only uses mcrypt, but I don't see any code path that actually calls the mcrypt-using function.
Those are not used on the Wikimedia cluster so the exercise can be left to their maintainers.
Meaning "more recently written"?
Yes, which means they could choose cryptographic primitives with more benefit of hindsight. Also it (well, NaCl wich Sodium is a fork of) was designed from the ground up to be resistant to side channel attacks which have been successfully used against OpenSSL in the wild.
But that's not too important, MediaWiki doesn't do any serious cryptography where the quality of the library would really matter. The main benefit for us is the increased availability.