Skip to content

Add a CI job for testing OpenSSL 1.1.1 bindings #135261

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
picnixz opened this issue Jun 8, 2025 · 5 comments
Open

Add a CI job for testing OpenSSL 1.1.1 bindings #135261

picnixz opened this issue Jun 8, 2025 · 5 comments
Assignees
Labels
3.13 bugs and security fixes 3.14 bugs and security fixes 3.15 new features, bugs and security fixes infra CI, GitHub Actions, buildbots, Dependabot, etc. tests Tests in the Lib/test dir

Comments

@picnixz
Copy link
Member

picnixz commented Jun 8, 2025

The minimal required OpenSSL version is 1.1.1 but we recommend to use OpenSSL 3.x and later for hashlib and ssl. However, we still have many code paths that are conditioned to OpenSSL versions and those are not eagerly tested. I suggest adding an SSL CI job for OpenSSL 1.1.1.

Ideally, I'd like to backport such job up to 3.9, but I'm not sure if I'm allowed to do this as it's not really a security issue.

Linked PRs

@picnixz picnixz added tests Tests in the Lib/test dir 3.13 bugs and security fixes 3.14 bugs and security fixes infra CI, GitHub Actions, buildbots, Dependabot, etc. 3.15 new features, bugs and security fixes labels Jun 8, 2025
@picnixz picnixz self-assigned this Jun 8, 2025
@ned-deily
Copy link
Member

FWIW, testing of 1.1.1 was deliberately removed in #123700 nine months ago.

@picnixz
Copy link
Member Author

picnixz commented Jun 8, 2025

I'll forward the comment I wrote on the PR here as well:

I do want it because we have code that is conditioned to OpenSSL version. And the (official) build requirements are still 1.1.1w so it makes sense to test this. Otherwise I don't know when we test those paths.

See https://docs.python.org/3/using/configure.html#build-requirements as well.

To be clear, the code paths that need to be tested are those in _hashlib, for instance:

#ifdef Py_HAS_OPENSSL3_SUPPORT
#define PY_EVP_MD EVP_MD
#define PY_EVP_MD_fetch(algorithm, properties) EVP_MD_fetch(NULL, algorithm, properties)
#define PY_EVP_MD_up_ref(md) EVP_MD_up_ref(md)
#define PY_EVP_MD_free(md) EVP_MD_free(md)
#else
#define PY_EVP_MD const EVP_MD
#define PY_EVP_MD_fetch(algorithm, properties) EVP_get_digestbyname(algorithm)
#define PY_EVP_MD_up_ref(md) do {} while(0)
#define PY_EVP_MD_free(md) do {} while(0)
#endif

cpython/Modules/_hashopenssl.c

Lines 2086 to 2103 in 8d17a41

#ifdef Py_HAS_OPENSSL3_SUPPORT
return EVP_default_properties_is_fips_enabled(NULL);
#else
ERR_clear_error();
int result = FIPS_mode();
if (result == 0) {
// "If the library was built without support of the FIPS Object Module,
// then the function will return 0 with an error code of
// CRYPTO_R_FIPS_MODE_NOT_SUPPORTED (0x0f06d065)."
// But 0 is also a valid result value.
unsigned long errcode = ERR_peek_last_error();
if (errcode) {
notify_ssl_error_occurred();
return -1;
}
}
return result;
#endif

Also, some constructions are deprecated in OpenSSL 3.0 but are still used (the HMAC_* interface is deprecated, and we should use EVP_MAC instead; this is #134531).

@ned-deily
Copy link
Member

Considering that the OpenSSL project officially ended unpaid support for 1.1.1 in 2023, I think we should consider updating our build requirements docs to exclude 1.1.1 rather than reintroduce 1.1.1 support in testing. At the moment the OpenSSL project offers at considerable expense extended support contracts for 1.1.1 . There are also vendors who provide paid extended support contract for various versions of Python. We could leave that support to them for users who need it.

@hugovk
Copy link
Member

hugovk commented Jun 8, 2025

See also recent discussion in #131423.

@picnixz
Copy link
Member Author

picnixz commented Jun 8, 2025

One relevant comment was #131423 (comment). And I actually agreed with dropping 1.1.1 requirements. It's just that my system-wide installation is 1.1.1. It's not an issue for me to upgrade it.

The advantage of dropping 1.1.1 is that it simplifies a lot the code, both in _hashopenssl.c and in _ssl.c. We can also drop the mnemonics from 1.1.1 that would be dead code. But I don't know about LibreSSL/BoringSSL that could be 1.1.1-ish. It's not officially supported, but it also doesn't cost much to keep it maintained for 1.1.1.

However, whatever we choose, if we keep it some code path that only works for OpenSSL 1.1.1, we should somehow test it (because now, we don't test it at all)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.13 bugs and security fixes 3.14 bugs and security fixes 3.15 new features, bugs and security fixes infra CI, GitHub Actions, buildbots, Dependabot, etc. tests Tests in the Lib/test dir
Projects
None yet
Development

No branches or pull requests

3 participants