GeezerVison is showing github.com — 3.7.17.9: move the 3.7 line to OpenSSL 3 by icanhasmath · Pull Request #126 · ActiveState/cpython
Conversation
icanhasmath
commented
Oct 30, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
Moves the 3.7 line from OpenSSL 1.1.1 (EOL September 2023; 1.1.1w is the last build in the inventory) to OpenSSL 3, as 3.7.17.9. The ActiveState 3.9.25.x and 3.10.22.x lines already ship OpenSSL 3.5.9 on Linux and Windows. This brings 3.7 to the same footing.
What's in it
- Upstream ssl changes the 3.9 line got for OpenSSL 3, cherry-picked with
-x:
- bpo-43794:
OP_IGNORE_UNEXPECTED_EOF by default. Without it, a peer that closes without close_notify raises SSLError: unexpected eof while reading instead of returning b''. That broke 103 cases across test_ssl, test_imaplib and test_urllib2_localnet, and it would break http.client, urllib and pip against many real servers.
- bpo-39953, bpo-40266, bpo-43788: per-version
_ssl_data error tables. With OpenSSL 3, 3.7's old table misnamed errors, for example [SSL: KRB5_S_TKT_NYV] unexpected eof.
- bpo-43789: the password callback is no longer called again after an error.
- Test updates: bpo-4379 and bpo-41561 (TLS 1.0/1.1 tests skip when unavailable), bpo-46114 (version check).
- Windows build.
PCbuild/openssl.props copied lib*-1_1.dll from the import-library directory. OpenSSL 3 puts its DLLs in bin\ and names them libssl-3.dll.
python.props now sets opensslBinDir: bin\ when the OpenSSL tree has one, otherwise the import-library directory.
openssl.props takes the DLL suffix from SSL_MAJOR_VERSION/SSL_MINOR_VERSION, which the Platform's python-builder sets. Without them it detects a 3.x OpenSSL from bin\ and otherwise assumes 1.1. The -x64 suffix is added only when such a DLL exists.
- This is the file shape
python-builder expects. Its NoSuffixOpenSSL step deletes the -x64 line and stops if the line is missing, the same as for 3.9 and 3.10. So 3.7.17.9 moves from python-legacy-builder (and its --legacy-ssl option set) to python-builder. The legacy builder's 1.1-only rewrite no longer matches this file.
- Release notes: a 3.7.17.9 section in
Doc/whatsnew/3.7.rst, including the behavior changes that come with OpenSSL 3 itself:
- the default security level refuses TLS 1.0/1.1, SHA-1 signatures and short RSA keys;
- MD4 and whirlpool are in the legacy provider;
- extension modules must be built against OpenSSL 3.
- Doc cleanup: removed the pasted citation markers (
NVD+5SUSE+5linux.oracle.com+5, starwindsoftware.com+2, ...) from the 3.7.17.7 notes, and fixed the short heading underlines of 3.7.17.4 through 3.7.17.7.
Not included
- bpo-43799 (
OPENSSL_API_COMPAT, OPENSSL_NO_DEPRECATED): it's only a deprecation-warning cleanup, and it depends on 3.9's rewritten _hashopenssl.c. With it, 3.7's _ssl.c would no longer compile. The build keeps its deprecation warnings.
- The 3.9 hashlib rework for OpenSSL 3 (bpo-40479): not needed. With OpenSSL 3.5.9, 3.7's hashlib behaves the same as 3.9's on the same OpenSSL:
md4 and whirlpool raise ValueError cleanly;
algorithms_available lists nothing unusable;
- pbkdf2, scrypt and hmac are unchanged.
Testing
- Linux x86_64, built against the Platform's OpenSSL 3.5.9 (headers and libraries from the 3.9.25.4 runtime):
- Before the ports, 3 of 17 SSL/hash-related modules failed:
test_ssl, test_imaplib and test_urllib2_localnet. All 17 now pass. The modules are test_ssl, test_hashlib, test_hmac, test_httplib, test_urllib2_localnet, test_imaplib, test_poplib, test_smtplib, test_ftplib, test_nntplib, test_asyncio, test_logging, test_urllib2, test_xmlrpc, test_ensurepip, test_venv and test_crypt.
- Full regrtest against a 1.1.1w build of 3.7.17.8, run side by side: 386 and 385 modules OK. The same five modules fail on both (
test_cmd_line, test_concurrent_futures, test_email, test_socket, test_urllib2), and no test case fails only on the OpenSSL 3 build.
- Linux, against OpenSSL 1.1.1w: the branch still builds, and
test_ssl, test_hashlib, test_imaplib, test_urllib2_localnet and test_httplib pass.
- Windows x64 (EC2 test box, VS 2022 v143), against the Platform's
shared/openssl 3.5.9 artifact:
- Built the way
python-builder builds: SSL_MAJOR_VERSION=3, SSL_MINOR_VERSION=5, and the -x64 line removed with the builder's own pattern (exactly one match). The build copies libcrypto-3.dll and libssl-3.dll with their .pdb files.
- A plain build with neither variable set copies the same DLLs.
ssl.OPENSSL_VERSION is 3.5.9.
- 13 modules pass:
test_ssl, test_hashlib, test_hmac, test_httplib, test_urllib2_localnet, test_imaplib, test_poplib, test_smtplib, test_ftplib, test_asyncio, test_logging, test_urllib2 and test_xmlrpc.
- The unclean-close and hashlib probes match Linux.
After merge
- Tag
v3.7.17.9.
- Inventory
language/python 3.7.17.9, starting from 3.7.17.8:
builder/python-legacy-builder becomes builder/python-builder, under the same condition 3.8.20.2 uses;
- drop the
legacy-openssl option set (--legacy-ssl);
- drop the
< 3 cap on shared/openssl;
- drop the Windows
shared/ffi < 3.4.6 cap. 3.7's _ctypes on Windows compiles the bundled libffi_msvc, so the Platform's libffi isn't linked and the libffi 3.5+ ctypes fix 3.9 and 3.10 needed doesn't apply;
- drop
windows-python-core-openssl eq 1.1.1u, which only the old non-alternative build path uses.
- Core-Python-3.7 rebuild, then core-qa on Windows and Linux against the 3.7.17.8 runtime.
- No GitHub CI runs on
3.7.17.x PRs, so the testing above is the verification.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
I updated the error codes using the OpenSSL 1.1.1f source tree.
(cherry picked from commit 3e0dd37)
openssl.props copied libcrypto-1_1.dll and libssl-1_1.dll from the import
library directory, so building against OpenSSL 3 failed at the copy step.
OpenSSL 3 installs its DLLs in bin\ and names them libssl-3.dll or
libssl-3-x64.dll depending on how it was built; both forms occur among the
Platform's shared/openssl 3.5 builds. python.props now sets opensslBinDir
(bin\ when OPENSSL_DIR has one, else the import library directory, which is
where 1.1 builds and the externals keep them), and openssl.props copies
whatever libcrypto-*/libssl-* DLLs and PDBs it finds there.
The ActiveState 3.9 builds get the same result from the Platform's core
patch, which computes the suffix instead.
The 3.7.17.7 section of Doc/whatsnew/3.7.rst carried source markers copied
along with its CVE descriptions ("NVD+5SUSE+5linux.oracle.com+5",
"starwindsoftware.com+2" and the like), which render as text. The
descriptions themselves are unchanged. The headings of the 3.7.17.4 to
3.7.17.7 sections also get underlines as long as their titles.
3.7.17.9 moves the 3.7 line to OpenSSL 3: the upstream ssl changes the
3.9 line got for OpenSSL 3 (unexpected-EOF handling, per-version error
tables, the password-callback fix and the matching test updates) and a
Windows build that copies OpenSSL 3's DLLs. The notes list the behavior
changes that come with OpenSSL 3 itself. OP_IGNORE_UNEXPECTED_EOF's
versionadded says 3.7.17.9, where this line gained it.
Copying libssl-*.dll by wildcard broke the Platform's python-builder,
which edits openssl.props and stops when its x64 suffix line is missing.
Name the DLLs from SSL_MAJOR_VERSION/SSL_MINOR_VERSION (set by the
Platform build), detect a 3.x OpenSSL from bin\ when they are unset, and
add the x64 suffix only when that DLL exists. python-builder removes
the x64 line, as it does for 3.9 and 3.10.
Co-Authored-By: Claude <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving.
Ports
All nine cherry-picks match their 3.9.25.x commits apart from 3.7 context: bpo-39953 ×2, bpo-40266, bpo-43789, bpo-43791, bpo-43794, bpo-43788, bpo-46114 and bpo-41561. The bpo-43788 and bpo-46114 picks leave out the CI and multissltests hunks, which is fine.
I checked the other OpenSSL 3 commits on 3.9.25.x. None of them is needed on 3.7:
- bpo-40479: both commits are N/A.
get_fips_mode() and usedforsecurity were added in 3.9.
- pythongh-100454 and the bpo-38820 commits: CI or doc-test changes only.
- bpo-43799: its exclusion is explained in the description.
Windows
- The
openssl.props / python.props change works with python-builder. The NoSuffixOpenSSL regex matches exactly the new -x64 line, and RenameSSLLibsStep only runs with --legacy-ssl, so libssl-3.dll keeps its name.
- 3.7's
_ctypes.vcxproj compiles the bundled libffi_msvc, so dropping the shared/ffi cap is safe.
Tests (Linux)
I built this branch and ran test_ssl, test_hashlib, test_hmac, test_httplib, test_urllib2_localnet, test_imaplib, test_poplib, test_smtplib, test_ftplib, test_nntplib, test_asyncio, test_logging, test_urllib2, test_xmlrpc, test_crypt and test_venv:
- OpenSSL 3.0.9: all 16 pass.
- OpenSSL 1.1.1n: all 16 pass.
- Base versions of
_ssl.c, _ssl_data.h, setup.py and test_ssl.py on OpenSSL 3.0.9: test_ssl, test_imaplib and test_urllib2_localnet fail.
🟡 Non-blocking
The release note says that at OpenSSL's default security level, "RSA keys shorter than 2048 bits are refused". That's level 2. OpenSSL 3's built-in default is level 1, where the floor is 1024 bits. 3.7's default cipher string (DEFAULT:!aNULL:...) doesn't raise the level, and level 1 already refuses SHA-1 signatures and TLS 1.0/1.1. Unless the Platform's OpenSSL is configured for level 2, this should say "shorter than 1024 bits".
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
… level
OpenSSL 3.2 raised the default security level from 1 to 2, so the floor
is 2048 bits on the 3.5 release the Platform builds with and 1024 bits on
3.0 and 3.1.
|
Thanks. On the security-level note: OpenSSL 3.2 raised the default level from 1 to 2, so both numbers are right, depending on the version. Your 3.0.9 run is at level 1. The Platform's 3.5.9 is built with OPENSSL_TLS_SECURITY_LEVEL 2.
I checked this build against the Platform's 3.5.9 with certificate verification on and OPENSSL_CONF=/dev/null:
- A default context refuses a 1024-bit RSA server key ("EE certificate key too weak") and accepts a 2048-bit one.
@SECLEVEL=1 accepts the 1024-bit key.
26a16fe rewords the release note to give both floors: 2048 bits on OpenSSL 3.2 and later, which includes the 3.5 the Platform builds with, and 1024 bits on 3.0 and 3.1.
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assigned
Milestone
No milestone
Development
Successfully merging this pull request may close these issues.
Uh oh!
There was an error while loading. Please reload this page.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
|