cryptography
cryptography copied to clipboard
Can legacy OpenSSL provider be optional?
Would it be possible to make legacy provider (when compiled with OpenSSL 3) optional? AFAICT, it's currently not really possible to use cryptography without a legacy provider being available, but I think it should be.
I tried removing the assert that checks for that:
--- cryptography-37.0.2/src/cryptography/hazmat/bindings/openssl/binding.py
+++ cryptography-37.0.2/src/cryptography/hazmat/bindings/openssl/binding.py
@@ -173,9 +173,6 @@ class Binding:
cls._legacy_provider = cls.lib.OSSL_PROVIDER_load(
cls.ffi.NULL, b"legacy"
)
- _openssl_assert(
- cls.lib, cls._legacy_provider != cls.ffi.NULL
- )
cls._default_provider = cls.lib.OSSL_PROVIDER_load(
cls.ffi.NULL, b"default"
)
and everything still seems to work (of course, without those legacy algorithms). The test suite is failing only where expected, and the code using cryptography I tested (Solaris package manager) works as anticipated.
Can something like this be done? Internally, I already made a patch that also handles missing legacy provider in the test suite (so it's fully green again); should I open a PR with it?
I’d be interested in supporting building without the legacy provider, but in addition to the test suite there probably needs to be reasonable error messages inside UnsupportedAlgorithm so users who run into this understand what has happened.
We’d also want to add a job to the test matrix that exercises this path and documentation about it.
That's true, currently it fails with a pretty ugly:
cryptography.exceptions.InternalError: Unknown OpenSSL error. This error is commonly encountered when another library is not cleaning up the OpenSSL error stack. If you are using cryptography with ano
ther library that uses OpenSSL try disabling it before reporting a bug. Otherwise please file an issue at https://github.com/pyca/cryptography/issues with information on how to reproduce this. ([_OpenSSLErrorWith
Text(code=50856204, lib=6, reason=524556, reason_text=b'error:0308010C:digital envelope routines::unsupported')]
so that is not good. I will look into it.
I think there's an important question here of what the API for this should be. It seems to me either:
- Users must explicitly opt into not loading the legacy provider - how do they specify this?
- We always try to load the legacy provider, but if it's not present we simply ignore it.
Maybe mirror the OpenSSL library itself - that is, if legacy provider is enabled globally (via the OpenSSL configuration file), then don't ask and just enable it (in which case I guess the _openssl_assert should still be there) and otherwise explicitly opt into it? Although I don't know how feasible that is.
Also, since the library currently calls OSSL_PROVIDER_load, the global configuration is ignored.
I created WIP PR #7391 for this (with the simplest changes I came up with that allow this).
Thanks for making this change (and sorry I didn't have time to look into it).
I have a follow-up question - do you expect this to be the permanent solution? I am asking because there is a reason why those algorithms are in the legacy provider and should not be used except for when you have a good reason. So it feels like it should be the other way around - environment variable to activate legacy algorithms.
That said, I do understand that for old applications, such a change is potentially a breaking one...
This is intended to be a medium term solution at least :-)
For now, this isn't a priority area to spend our backwards incompatibility budget.
The symmetric algorithms in question are also generally deprecated. (The exception is that we have no mechanism to state that an encrypted serialization uses deprecated cryptography...and almost all of it does)
I see. Well, making the legacy provider optional is the important thing, so thank you.