Visualizing the CPython Release Process

This critical role would not be possible without funding from the OpenSSF Alpha-Omega Project. Massive thank-you to Alpha-Omega for investing in the security of the Python ecosystem!

Last week I met with the CPython Developer-in-Residence and Release Manager Łukasz 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.

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 risk§

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 CNA§

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 items§

• 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 next week's report or last week's report.

Thanks for reading! ♡ Did you find this article helpful and want more content like it? Get notified of new posts by subscribing to the RSS feed or the email newsletter.