Specify minimum compatibly when building with openssl

[mspiller]

We are building cryptography ourself on a system using system openssl 3.2.0 but we want to achieve minimum compatibility with openssl 3.0.8. The reason is that we want to use system openssl because it is patched faster in case of CVE and not using bundled openssl like it is on PYPI.

Based on the header for openssl it should be possible to set (via -DOPENSSL_API_COMPAT=30000 variable) the compatibility level.
However it is currently not possible to specify the compatibility level of openssl in cryptograpy.

For example how to use this in C:
https://github.com/openssl/openssl/blob/3d68b70b9e4f36509a8adf63221bf24b3cc18052/include/openssl/macros.h#L84-L87

While cryptography allows to specify CRYPTOGRAPHY_BUILD_OPENSSL_NO_LEGACY it does not allow you to change DEP_OPENSSL_VERSION_NUMBER that we want to target (because it is set from openssl rust project).

Would it be possible to override the openssl version to target lower openssl. Perhaps using additional OPENSSL_API_COMPAT before checking DEP_OPENSSL_VERSION_NUMBER.

The logic that depends and includes 3.2 symbols is:

cryptography/src/rust/src/lib.rs

Lines 245 to 256 in 1aae69a

	if #[cfg(CRYPTOGRAPHY_OPENSSL_320_OR_GREATER)] {
	use std::ptr;
	use std::cmp::max;
	let available = std::thread::available_parallelism().map_or(0, |v| v.get() as u64);
	// SAFETY: This sets a libctx provider limit, but we always use the same libctx by passing NULL.
	unsafe {
	let current = openssl_sys::OSSL_get_max_threads(ptr::null_mut());
	// Set the thread limit to the max of available parallelism or current limit.
	openssl_sys::OSSL_set_max_threads(ptr::null_mut(), max(available, current));
	}
	}

[reaperhulk]

I’m not sure I understand the request. There is no need to set the OpenSSL API compatibility level to compile against system OpenSSL — you can just point the build system at the system headers and library and it will use them without issue. Is that not working for you?

[mspiller]

We are preparing cryptography wheel on our build environment with latest Amazon Linux 2023 that is using openssl 3.2.0 but we are deploying to couple of server that are still running Amazon Linux 2023 but they use 3.0.8 version of openssl. And we were hoping to achieve the compatibility during build process. Usually this is achieved by defining OPENSSL_API_COMPAT.

Currently it fails when trying to load cryptography due to missing symbol:

OSSL_set_max_threads@OPENSSL_3.2.0
OSSL_get_max_threads@OPENSSL_3.2.0

[reaperhulk]

So you want to take advantage of forward ABI compatibility with dynamic linking, okay. Thanks for clarifying!

I think this sort of capability really needs to live upstream with rust-openssl to be properly supported. Thoughts @alex?

[alex]

I'm not wild about this, it seems like it will be challenging to test to ensure correctness. What's the motivation to not compile against an OpenSSL that matches your target one?

[mspiller]

We are using one (offline) environment to build all the python packages. And it works for most of them. Even confluent-kafka also using openssl. We have very limited number of old instances but they are still present in our system due to up time requirements and hard to upgrade.

Using old environment would be troublesome because old image uses very older rust version that we cannot then build bunch of stuff like ruff, even cryptography (rust 1.68.0). Also pyarrow can be installed only on latest Amazon Linux.

Yes, we could have multiple environment but it would be harder to maintain.

My proposal would be to have a positibility to override compatibility of DEP_OPENSSL_VERSION_NUMBER with CRYPTOGRAPHY_OPENSSL_VERSION_NUMBER like we currently already use for CRYPTOGRAPHY_BUILD_OPENSSL_NO_LEGACY. Basically if cryptography does not import new functions it should work (and it works). From docs minimum compatibility required by cryptography is 3.0.

[alex]

Just to be clear: this isn't something that can be implemented in cryptography, it'd have to be implemented in rust-openssl.

…

On Fri, Sep 5, 2025 at 2:30 AM mspiller ***@***.***> wrote: mspiller left a comment (pyca/cryptography#13393) We are using one (offline) environment to build all the python packages. And it works for most of them. Even confluent-kafka also using openssl. We have very limited number of old instances but they are still present in our system due to up time requirements and hard to upgrade. Using old environment would be troublesome because old image uses very older rust version that we cannot then build bunch of stuff like ruff, even cryptography (rust 1.68.0). Also pyarrow can be installed only on latest Amazon Linux. Yes, we could have multiple environment but it would be harder to maintain. My proposal would be to have a positibility to override compatibility of DEP_OPENSSL_VERSION_NUMBER with CRYPTOGRAPHY_OPENSSL_VERSION_NUMBER like we currently already use for CRYPTOGRAPHY_BUILD_OPENSSL_NO_LEGACY. Basically if cryptography does not import new functions it should work (and it works). From docs minimum compatibility required by cryptography is 3.0. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.