Skip to content

Add a CI job for testing OpenSSL 1.1.1 bindings #135261

Open
@picnixz

Description

@picnixz

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

Activity

added
testsTests in the Lib/test dir
3.13bugs and security fixes
3.14bugs and security fixes
infraCI, GitHub Actions, buildbots, Dependabot, etc.
3.15new features, bugs and security fixes
on Jun 8, 2025
self-assigned this
on Jun 8, 2025
ned-deily

ned-deily commented on Jun 8, 2025

@ned-deily
Member

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

picnixz

picnixz commented on Jun 8, 2025

@picnixz
MemberAuthor

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

ned-deily commented on Jun 8, 2025

@ned-deily
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

hugovk commented on Jun 8, 2025

@hugovk
Member

See also recent discussion in #131423.

picnixz

picnixz commented on Jun 8, 2025

@picnixz
MemberAuthor

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)

gpshead

gpshead commented on Jun 10, 2025

@gpshead
Member

@WillChilds-Klein may be able to provide CI or buildbot setup to help us maintain AWS-LC shaped support (per the discuss thread).

WillChilds-Klein

WillChilds-Klein commented on Jul 3, 2025

@WillChilds-Klein
Contributor

PR for AWS-LC testing in CI is here. AWS-LC's libssl "looks like" OpenSSL 1.1.1's libssl, but we can't provide any strong compatibility guarantees there through time, neither for API nor ABI (particularly not ABI). If OpenSSL 1.1.1 is a meaningful target, it should be tested independently. But, I hope and expect that OpenSSL users will migrate to OpenSSL 3.x as OpenSSL resolves performance gaps between 1.1.x and 3.x.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

3.13bugs and security fixes3.14bugs and security fixes3.15new features, bugs and security fixesinfraCI, GitHub Actions, buildbots, Dependabot, etc.testsTests in the Lib/test dir

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    Add a CI job for testing OpenSSL 1.1.1 bindings · Issue #135261 · python/cpython

    Follow Lee on X/Twitter - Father, Husband, Serial builder creating AI, crypto, games & web tools. We are friends :) AI Will Come To Life!

    Check out: eBank.nz (Art Generator) | Netwrck.com (AI Tools) | Text-Generator.io (AI API) | BitBank.nz (Crypto AI) | ReadingTime (Kids Reading) | RewordGame | BigMultiplayerChess | WebFiddle | How.nz | Helix AI Assistant