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:
tar.xzsource files for the Python release. This includes building the updates documentation.
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.
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):
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!
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.
Don't let social media algorithms decide what you want to see.
This work is licensed under