I’ve done some thinking and I believe that Software Bill-of-Materials documents could be created for release streams of CPython that already exist and made public in CPython patch releases, here is my thinking:
- Software Bill-of-Materials isn’t a CPython feature, it’s more analogous to the Sigstore signatures of CPython, being only an artifact that’s “released” alongside the actual CPython releases. Sigstore signatures were introduced in a patch version of CPython with separate announcements and documentation outside of the CPython release and docs.
- Releasing only a single SBOM for the latest version of CPython would vastly limit its utility as we know that many users will be using older CPython versions for some time. Given we have the ability to create these artifacts it makes sense to do so for those users.
- Security releases are just as likely to receive updates to bundled dependencies due to vulnerabilities and users would benefit from knowing when to upgrade based on that information (and when they don’t need to upgrade due to a dependency that has a CVE, but isn’t vulnerable in our usage). That is the primary use-case that SBOMs with VEX so we want to encourage users to not need to ask for security releases that are unnecessary.
- Release tooling needs to be able to handle more than one release stream anyways, having that running live instead of hypothetically will help with integration.
- It’s likely that everything will be in place to deliver a Software Bill-of-Materials for CPython in the first quarter of 2024. Having to wait artificially until October for 3.13.0 to be released doesn’t feel necessary for this sort of development.
Thus my proposal is to backport the existing Software Bill-of-Materials infrastructure and tooling that currently exists in the CPython repository to security-fix branches. I’ll run this proposal by release managers.