https://sethmlarson.dev/security-developer-in-residence-weekly-report-9?date=2023-09-05 About | Blog | Newsletter Visualizing the CPython Release Process Published 2023-09-05 by Seth Larson Reading time: 3 minutes Last week I met with the CPython Developer-in-Residence and Release Manager Lukasz Langa to discuss the release process for CPython (detailed in PEP 101). Everything I learned I've documented below and will be proposing enhancements like introducing additional hardening for the release process and capturing Software Bill of Materials for the build process and the final built artifacts. Release Tool Release Tool v3.X.XaN v3.X.XaN git commit git tag git commit... Source Tarballs Source Tarbal... Binary Installer Signatures Binary Instal... Windows Release Manager Windows Relea... Release Manager Release Manag... CPython Upstream Repo CPython Upstr... Azure Pipelines Azure Pipelin... macOS Release Manager macOS Release... macOS Build Process macOS Build P... Freeze Release Branch Freeze Releas... Windows embeddable packages Windows embed... Windows installers Windows insta... Nuget Nuget macOS Installer macOS Install... Windows Store Windows Store Source Tarballs Source Tarbal... Binary Installers Binary Instal... Source Tarball Signatures Source Tarbal... python.org python.org PyPI Packages PyPI... quay.io autoconf image quay.io autoc... Sigstore + GPG Sigstore... CPython RM Fork Repo CPython... Linux Distro Packages Linux Distro... CPython Binary Deps CPython Binar... CPython Source Deps CPython Sourc... Legend Legend git push git pu... Human Actor/Task Human Actor/T... Release Artifact Release Artif... Source of Risk Source of Risk Start / End State Start / End S... 1 1 2 2 3 3 4 4 5 5 6a 6a 6b 6b 6c 6c 8 8 9 9 10 10 Test Artifacts Test Artifacts 7 7 N N Step Number Step Num...Text is not SVG - cannot display Below are the high-level steps (with numbers corresponding to the above diagram) in the order they occur during the CPython release process: 1. Freeze the python/cpython release branch. This is done using GitHub Branch Protections. 2. Update the Release Manager's fork of python/cpython. 3. Run Python release tools (release-tool, blurb, sphinx, etc). 4. Push diffs and signed tag to Release Manager's fork. 5. Git tag is made available to experts for Windows and macOS binary installers. 6. Source tarballs, Windows, and macOS binary installers built and tested concurrently. + 6a: Release manager builds the tgz and tar.xz source files for the Python release. This includes building the updates documentation. + 6b: Windows expert starts the Azure Pipelines configured to build Python. + 6c: macOS Expert builds the macOS installers. 7. All artifacts (source and binary) are tested on their platforms. 8. Release manager signs all artifacts using Sigstore and GPG. 9. All artifacts are made available on python.org. 10. After artifacts are published to python.org, the git commit and tag from the Release Manager's fork is pushed to the release branch. This list is focused on areas of supply-chain risk, there's more involved in creating a CPython release than is documented here, like checking for release blocker issues, ensuring that buildbots are stable, running the full test suite, differences between final, bugfix, security, and end-of-life releases, purging the CDN, and updating the website. Sources of supply chain riskSS If you've ever seen SLSA's "Supply chain threats" diagram (which is reaching XKCD levels of ubiquity within open source security discussions) you'll recognize a few places where there is risk to mitigate (with real-world examples): * Compromise source repository (PHP) * Build from modified source (Webmin) * Use compromised depedency (event-stream) * Compromise the build process (SolarWinds) * Upload modified package (Codecov) * Compromise package repository (Package Mirrors) I'll be working with the CPython release managers on mitigating the above threats in the CPython release process. I'll also be adding Software Bill of Materials (SBOM) creation so consumers of Python can confidently use Python where SBOMs are required for compliance. Stay tuned! Python Software Foundation authorized as a CNASS Last week the Python Software Foundation was announced as a CNA! I've been working on this for the past month and a half and am excited to share what we learned with other Open Source organizations and projects. Other itemsSS * Investigated the "Bring Your Own Builder" feature from SLSA for applicability to a Python GitHub Actions builder. * Submitted my draft for "Becoming a CNA as an Open Source Org/ Project" to OSSF Vuln Disclosures WG and CNA Community Outreach WG. + https://github.com/ossf/wg-vulnerability-disclosures/issues/ 138 + Also sent to a few Open Source orgs/projects interested in the CNA Program. * Participated in OSSF SBOM SIG for "Best Practices for Naming and Directory Conventions for SBOMs in Open Source Projects" * Provided an August update for OpenSSF Alpha-Omega. That's all for this week! If you're interested in more you can read last week's report. Subscribe to be notified of more content like this through the email newsletter or RSS.