PEP 770: Improving measurability of Python packages with Software Bill-of-Materials

[sethmlarson (Seth Michael Larson)]

@rgommers

The “does it have to be dynamic” question was pretty much the first question that came up for me. It is a little odd that the PEP doesn’t contain the word “dynamic” at all, and all the examples are for static metadata, while it looks like the design more or less forces dynamic usage it seems from the discussion.

So there’s three use-cases that are supported:

• Specifying SBOM files statically that are included in source (eg: pip bundling software in pip/_vendor).
• Build backends can generate an SBOM document that gets included in the wheel (e.g: maturin generating an SBOM for Cargo.lock)
• Other tools which modify a wheel can include additional SBOM documents (e.g: auditwheel repair)

The bottom use-case has nothing to do with dynamic because auditwheel isn’t a build backend. For the other two, SBOMs that were generated by the build backend would require dynamic to be used.

However, one case that I didn’t think of is if a project wants both statically bundled and dynamically generated SBOM documents. I don’t think this would be a common situation, but I can imagine a project wanting both? Especially if a build backend wants to add automatic SBOM document generate without requiring its users to opt-in, this could cause issues if those users are already manually specifying SBOMs.

If we want to eliminate dynamic we would need to move to specifying a single directory (Sbom-Dir/project.sbom-dir?) which I believe was suggested earlier in the thread. This would be an entirely new “mechanic” for specifying multiple files in a Python archive (compared to PEP 639 and license-files) but I don’t view that as a blocker?

So in the case that projects want to support both static and dynamic SBOMs they’d specify project.sbom-dir for their static SBOMs and then build backends (and auditwheel) would need to generate and place their SBOM documents into the pre-defined directory with a mechanism for ensuring there are no name collisions (subdirectories could work here).

@rgommers

is it feasible for auditwheel to start amending an existing SBOM file/template? That could keep it in the realm of static. If auditwheel can only emit a separate file, then it’s dynamic in nature. The former would be nicer. Is there a way to implement that @sethmlarson, at least for CycloneDX and SPDX?

Hmm, this isn’t my understanding of “dynamic” for pyproject.toml which is that it only applies to build backends and not tools that are modifying the archives post-build, is that assumption incorrect?

Answering whether it’s possible to implement, it’s possible but even dedicated tools for this task are quite involved which is why I wanted to push the problem downstream where they have to implement multiple SBOM standards and “merging” anyways.

@rgommers

It would also be nice if the PEP included a more realistic example. You mention the Pillow case multiple times, so why not include that as a worked example?

I do link out to the example project and a blog post describing the project in the PEP, but I can make other more 1-to-1 example project configurations for this.

@rgommers

Final comment: the motivation explains that Python packaging metadata cannot describe non-Python software components. It’d be good to point out that PEP 725 aims to solve a significant part of that metadata gap.

I’ll add a reference to PEP 725 about how the two standards compliment each other, thanks!