The video from my talk at #fosdem2024 is now live. See the exciting changes that @yoctoproject and @OpenEmbeddedOrg have coming soon with the migration from @SPDX_SBOM version 2.2 to 3.0 youtu.be/y3m_0YTjsnw?si=DjJO… via @YouTube

One goal of the transition to SPDX 3.0 is to make it possible to associate a build with the SBoM of the machine that did the build. Potentially we might even be able to do this across sstate someday

@OpenEmbeddedOrg @yoctoproject

My talk from #fosdem23 on SBoM generation at build time using #openembedded and #yocto as a case study is now available youtu.be/Q5UQUM6zxVU Or fosdem.org/2023/schedule/eve…

The example SBoM from my presentation can be downloaded here: drive.google.com/file/d/1wK5…

But, yes it does link your relationships to the document they live in, which is not ideal

Right. External references are allowed by the spec, but as you point out hard to deal with. Combining all packages into a single document would work better (and eliminate our tar archive), however this is difficult with SPDX 2 because it has to be a contextual merge.

Not quite. It is a relationship between a package in the current document and a package in another document. The ":" splits the ID between the External Document Reference (defined in this document) and the package name in that external document

Ah yes. That's a question for @SPDXTeam :)

You are correct, many of our documents contain a single package, so I sometimes incorrectly talk about relationships between packages as relationships between documents.

The @yoctoproject and @OpenEmbeddedOrg have been around for quite a while, and there are many examples of large companies using it to build complex products

The recipe metadata is designed to be simple to maintain correctly, and easy to share. For example, you wouldn't need to write the recipe to compile zlib because we already have one.

The QA checks provided by the project are mostly automatic

I'm also working with @SPDXTeam to develop SPDX 3.0 so it should have better support for our uses from the first release, and I hope to be an early adopter

Consuming the SPDX we generate is not currently easy. It is valid SPDX, but I haven't seen any tools that can deal with the complexity. However, is providing a concrete example should help the tooling evolve more quickly.

e.g. a poorly written recipe may produce poor SPDX

There is recipe metadata that describes the software. It's "authoritative" in that we only put in the SPDX what is described in the recipe metadata or the source itself. You are at the mercy of the quality of the recipe, but we have QA checks to help with that

Lean how to track your Software Bill of Materials with #SPDX using the Yocto Project and OpenEmbedded in my latest talk from the Embedded Linux Conference: youtu.be/6zms_qGmVqg @linuxfoundation @OpenEmbeddedOrg @yoctoproject @SPDXTeam

My nephew used call online gaming friends "imaginary friends"

Well, the kernel is "close to the metal"