@stacktrust@balister 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
My talk from #fosdem23 on SBoM generation at build time using #openembedded and #yocto as a case study is now available
https://t.co/XphctBIBqZ
Or
https://t.co/Po4Cf7XEgg
@YevTheDev@SPDXTeam@linuxfoundation@OpenEmbeddedOrg@yoctoproject I took the description of relationship fields in https://t.co/dOLqBWkxJu to mean that External Document References are allowed in relationships; the document creation information gives a local "shorthand" name for the external document you want to reference.
@YevTheDev@SPDXTeam@linuxfoundation@OpenEmbeddedOrg@yoctoproject 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.
@YevTheDev@SPDXTeam@linuxfoundation@OpenEmbeddedOrg@yoctoproject 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
@YevTheDev@SPDXTeam@linuxfoundation@OpenEmbeddedOrg@yoctoproject 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.
@YevTheDev@SPDXTeam@linuxfoundation@OpenEmbeddedOrg@yoctoproject 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