Add system-OpenSSL build variant for the bundled Python 3.10.13 Linux package

[nickschuetz]

Summary

Adds a parallel Linux build variant for the bundled Python 3.10.13 package that links dynamically against the building distro's system OpenSSL 3.x rather than the bundled OpenSSL-1.1.1t-rev1-linux static dependency.

Motivation

The bundled OpenSSL-1.1.1t is end-of-life since 2023-09-11. For downstream distribution packagers (Fedora, Debian, Arch, Alpine) targeting their distribution's review process, the EOL crypto in the bundled Python is a meaningful inclusion blocker. This variant gives those packagers a clean path: configure Python to find OpenSSL 3.x in the system at build time, link dynamically, let the OS handle CVE updates.

What this PR does

The existing linux_x64/ variant is unchanged. A new Linux-system-openssl sub-variant in build_config.json triggers an env-var (PYTHON_USE_SYSTEM_OPENSSL=1) that the modified docker_build_linux.sh reads. In that mode:

• --with-openssl=/usr --with-openssl-rpath=auto replaces --with-openssl=<bundled path>
• The Ubuntu base image has libssl-dev available (added to the Dockerfile)
• _ssl.cpython-310-x86_64-linux-gnu.so ends up dynamically linking against the OS's libssl.so.3 + libcrypto.so.3

Output package: python-3.10.13-rev1-linux-system-openssl. Drop-in replacement for downstream consumers whose target OS provides OpenSSL 3.x; Python ABI is 3.10.13 stable.

Compatibility

The new variant requires the target system to have OpenSSL 3.x in the base OS at runtime (libssl.so.3 + libcrypto.so.3). Target distros with OpenSSL 3.x in base: Ubuntu 22.04 LTS and newer, Fedora 39 and newer, RHEL 9 and newer, Debian 12 and newer. Existing consumers on older OSes (Ubuntu 20.04 LTS, RHEL 8, Debian 11) ship OpenSSL 1.1.x and would not work with the system-openssl variant; they keep using the existing linux_x64/ variant unchanged. Offline-install scenarios on older targets are unaffected because the default bundled variant is fully self-contained.

Validation

Spike validation completed locally before this PR. Net: 78 individual checks across the integration tier suite, 0 failures.

Build: PASS. Full pull_and_build_from_git.py package-system/python --platform-name Linux-system-openssl --clean ran clean inside an Ubuntu 22.04 container. Configure detected system OpenSSL (checking for openssl/ssl.h in /usr... yes), and the Building Python against system OpenSSL (dynamic link) env-var-driven branch executed correctly. Final PYTHON WAS BUILT FROM SOURCE marker reached.

Artifact:

• ldd _ssl.cpython-310-x86_64-linux-gnu.so shows libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 + libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (Ubuntu container). On a Fedora 44 host, resolves to /lib64/libssl.so.3 + /lib64/libcrypto.so.3 (OpenSSL 3.x stable ABI holds across the build-host / runtime-host boundary).
• import ssl; print(ssl.OPENSSL_VERSION) returns OpenSSL 3.0.2 15 Mar 2022 (Ubuntu 22.04 container) and OpenSSL 3.5.5 27 Jan 2026 (Fedora 44 host).
• Non-OpenSSL Python C extensions still carry Ubuntu SONAMEs (unchanged from the existing bundled Python; this PR doesn't regress that).

Engine smoke (downstream Fedora packaging effort):

• Swapped the rebuilt Python into the engine install path, wiped ~/.o3de/Python/venv to force re-bootstrap via get_python.sh, ran the integration tier suite.
• Tier 1 (RPM integrity): PASS
• Tier 2 (install integrity + system-swap auto-Requires): PASS
• Tier 3 (cold-cache first-run setup via get_python.sh, manifest registration via o3de-cli register --this-engine): PASS. This is the critical OpenSSL-path canary: pip install runs HTTPS through the rebuilt _ssl module; manifest setup and registry work correctly.
• Tier 4 (engine binary smoke, Project Manager Python init): PASS
• Tier 5 (project create via Python-driven o3de create-project + cmake configure): PASS
• Tier 9 (MultiplayerSample warm-cache build + bake + GameLauncher load): 13/13 PASS
• Tier 10 (NewspaperDeliveryGame warm-cache build + bake + launcher loaded CharacterSample): 7/7 PASS

The engine works identically with the rebuilt Python. AssetProcessor's embedded Python interpreter executes builders cleanly. PySide2 (separate bundled package, links against libpython3.10.so.1.0) loads without ABI issues; Python's stable patch-level ABI held.

Open questions for sig-build

1. Default Dockerfile base image: Ubuntu 20.04 ships OpenSSL 1.1.1f. For the system-openssl variant the build needs Ubuntu 22.04 (OpenSSL 3.0.2) or 24.04 (OpenSSL 3.0.13). Two options: (a) parameterize the base image via build_config.json so each variant picks its own (preserves existing artifact-byte-equivalence for the bundled-OpenSSL build), or (b) bump the default base to 22.04 for both variants (simpler maintenance). Happy to refactor either way.
2. Naming: python-3.10.13-rev1-linux-system-openssl is verbose. Alternatives: python-3.10.13-rev1-linux-dynamic-ssl, python-3.10.13-system-ssl-rev1-linux, etc. Whatever convention sig-build prefers.
3. Should the dynamic variant eventually become the default? Long-term, dynamic-link-against-system-OpenSSL reduces O3DE maintainers' CVE-response burden (system updates flow through apt-get update / dnf update instead of requiring a Python rebuild every time OpenSSL ships a CVE). The bundled variant remains useful for environments where system OpenSSL can't be assumed (older containers, embedded targets, build-isolated CI, air-gapped offline-install on older OSes). Suggest both variants coexist long-term.

Notes

• aarch64 variant follows the same shape; happy to add in a follow-up once x86_64 is validated and the naming / base-image questions are settled.
• Filed in coordination with the downstream Fedora packaging effort at https://github.com/nickschuetz/o3de-rpm. See that repo's upstream-drafts/pr-python-system-openssl.md for the full motivation and validation evidence.