Identifying a uv-style CPython 3.12.14 build and its _ssl/OpenSSL patch provenance

[MattsGlobal]

Hello,

We are trying to identify the build provenance of a Linux x86-64 CPython interpreter
found in a uv-managed-style installation directory. We have not established the
original release asset or download record, so we are asking whether these identifiers
can be mapped to a python-build-standalone release, rather than assuming they can.

Our saved inspection records:

• CPython: 3.12.14 (main, Sep 1 2026, 14:16:52), Clang 22.1.3.
• Runtime OpenSSL: OpenSSL 3.5.8, 25 Aug 2026.
• _ssl: builtin, not a separately loaded extension.
• Executable size: 30,913,848 bytes.
• Executable SHA-256:
  f7c6210eb40fadcd3c2889dddd24a15fc2c9f926aec5a03bf9da66e12d581526
• ELF build ID: 1b4adbcfef173a5a342e67de1b23f751d763439a.
• Saved configuration includes MODULE_BUILDTYPE=static, optimizations, LTO and BOLT.
• The bounded inspection did not locate PYTHON.json or an immutable source/patch
  mapping. We understand install-only distributions can omit full build metadata.

Can you identify the corresponding release/asset or the smallest nonsecret metadata
needed to identify it? If it is one of your builds, where are the immutable CPython
and OpenSSL source revisions, build recipe, and applicable patches recorded? In
particular, does that build carry any _ssl per-connection synchronization or lifetime
patches beyond its upstream sources?

This arose while investigating a private cryptocurrency paper-simulation project.
The symptoms under review are exclusively from local synthetic TLS/WebSocket fixtures;
we are not requesting exchange help or alleging a vulnerability in your distribution.
The fixture uses websockets 17.1 and sometimes times out during a second opening after
TLS. Saved Python traces show receive/send call lifetimes overlapping on one SSL
socket in successful samples too. We have not proved native simultaneous execution
or identified the cause. We are keeping the API-ownership question separate from
this build-provenance request.

No project source, credentials, infrastructure addresses, headers, private logs or
binary is attached. We have not obtained a deterministic minimal upstream reproducer
and are not claiming that this question establishes the cause of the timeout.

Prepared with AI assistance; the identifiers and observations above are from saved
inspection records. Thank you for pointing us to the appropriate provenance records
or a more suitable project channel.

[jjhelmus]

From the description this sounds like it comes from the install_only_stripped distribution for Linux x86-64, Python 3.12 part of the 20260901 release.

Specifically the file

• cpython-3.12.14+20260901-x86_64-unknown-linux-gnu-install_only_stripped.tar.gz
• SHA256 72748da13197c1fb161e3afeef20a6a385ff24f2165e6e2758e47008e7faba4c

# curl -SLO https://github.com/astral-sh/python-build-standalone/releases/download/20260901/cpython-3.12.14+20260901-x86_64-unknown-linux-gnu-install_only_stripped.tar.gz
...
# tar xf cpython-3.12.14+20260901-x86_64-unknown-linux-gnu-install_only_stripped.tar.gz
# ./python/bin/python
Python 3.12.14 (main, Sep  1 2026, 14:16:52) [Clang 22.1.3 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
# ls -l python/bin/python3.12
-rwxrwxr-x 1 root root 30913848 Jan  1  2024 python/bin/python3.12
# sha256sum ./python/bin/python3.12
f7c6210eb40fadcd3c2889dddd24a15fc2c9f926aec5a03bf9da66e12d581526  ./python/bin/python3.12
# readelf -n ./python/bin/python3.12
...
Displaying notes found in: .note.gnu.build-id
  Owner                Data size 	Description
  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: 1b4adbcfef173a5a342e67de1b23f751d763439a

[MattsGlobal]

Thank you @jjhelmus — this is extremely helpful.
The extracted interpreter details you provided match our saved executable exactly, including the Python build timestamp/compiler, executable size, SHA-256 and ELF build ID. That gives us the exact provenance we were trying to establish and identifies the interpreter as the 20260901 Linux x86-64 install_only_stripped distribution.
It also explains why our installed copy did not contain the full build metadata we had been looking for.
We really appreciate you taking the time to reproduce this and verify the exact artifact. We’ll use the 20260901 release/source as the authoritative baseline for the remaining _ssl/OpenSSL review.
Thank you again!

[nazeeh111]

The first reply identified the exact stripped asset. For the remaining source and patch provenance, the 20260901 recipe pins source archives (not Git checkouts):

• CPython 3.12.14: the official Python-3.12.14.tar.xz source archive, SHA-256 5c8462af5790baf43a321a1559dbe0db06d1be4300fb85fb53c40060668e548a.
• OpenSSL 3.5.8: openssl-3.5.8.tar.gz, SHA-256 a8f84a39918ec6415ce765d9b429d313ba97b8143169c172e734b9514464f5b2.

Both pins are in pythonbuild/downloads.py. The immutable 20260901 source tag contains the build recipe: build-cpython.sh extracts the pinned CPython archive and configures it with --with-openssl=.../deps; build-openssl-3.5.sh builds the pinned OpenSSL archive.

For this Linux build, I found no downstream _ssl per-connection synchronization or lifetime patch in the release-tagged CPython patch recipe. The relevant downstream changes are different: patch-cpython-redhat-cert-file.patch adds fallback CA paths for older RHEL/Fedora systems, and the Linux-only patch in build-openssl-3.5.sh accepts the rh-allow-sha1-signatures configuration key as a no-op. Neither changes TLS connection locking or object lifetime. The module manifest lists _ssl as built from _ssl.c and linked with ssl and crypto.

The stripped install-only archive omits PYTHON.json by design; the archive documentation says the full .tar.zst retains it and build artifacts. The release-tagged source pins and recipe above identify the inputs independently. This is a source-recipe audit, not a reproduction of the WebSocket timeout or a claim about its cause. Prepared with Codex assistance.