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!
The past week has been almost exclusively writing for me! Here's a rundown on what I've been writing about:
As many folks in the Open Source security space are aware of, the deadline for the US Government RFI submissions (November 9th, 2023) is fast-approaching! I've been working with my colleagues at the Python Software Foundation to draft a response to the RFI over the past months now. The past few weeks have had a lot of time spent on collaborating and refining our response to the point where I am quite proud of it now.
The Python Software Foundation's response to the RFI is about capturing what we believe is important regarding the US governments approach to securing open source software. Whatever gets done by the US government is likely to have huge implications for everyone maintaining and consuming open source software, so it's critical that policy and decisions are made with sustainability in mind.
I'm honored to be a part of this and to represent so many Pythonistas in my work both for this RFI and every day as Security Developer-in-Residence. 💜
Throughout the process of joining the CVE Numbering Authority program for the Python Software Foundation I noted down all the steps and requirements to become a CNA. I transformed these notes into a digestible document that's specifically written for Open Source projects and organizations. This document has had extensive review from both the OpenSSF Vulnerability Disclosures Working Group and multiple CVE Working Groups.
This guide has recently been published under the OpenSSF Vulnerability Disclosures WG GitHub repository. I'm now in the process of drafting an announcement blog post for the OpenSSF blog.
I've raised my hand to help PEP 639 make its way to acceptance as this PEP was one that I noted as being important for Software Bill-of-Materials being adoptable for the Python packaging ecosystem. I wanted to also thank Karolina Surma who works on Python packaging at Red Hat for joining as a coauthor of PEP 639 as well and is already making use of the PEP. Thanks so much!
The gist of this PEP is to move package tooling and maintainers to adopt SPDX License IDs and expressions
in order to more accurately represent the licenses of Python packages. Previous standards would use an open-ended string
License field along with
License :: * trove classifiers.
This approach isn't able to capture all licensing situations (such as
'MIT OR GPL-2.0-only') and especially struggles with license revisions.
Due to the inability to capture these more complication situations, it often meant that tooling consuming Python packages would need to look at
files and do their own text detection in order to have an accurate view of the licensing situation. Choosing a license is one of the more important decisions
before releasing software into the wild, so ensuring that that choice is unambiguous is very important!
Don't let social media algorithms decide what you want to see.
This work is licensed under