On Sat, 2023-02-04 at 15:47 -0600, Alex Stewart wrote: > On 2/3/23 17:06, Richard Purdie wrote: > > On Fri, 2023-02-03 at 12:26 -0600, Alex Stewart wrote: > > > Hey Josh, > > > > > > I have been roadmapping SBOM generation for NI's yocto distro and have a > > > few open questions about the future of SPDX and the create-spdx bbclass. > > > Since your name seems to be attached to both of those, I figure you > > > might have the best insight here. > > > > > > Also posting to the OE-core ML so that this discussion can help other > > > members. > > > > > > > > > 1. SPDX 3 timeline. I hear that SPDX 3 is going to be a complete rewrite > > > of the spec, with more support for modern SBOM discussion topics like > > > VEX and more comprehensive vulnerability tracking. And it also seems to > > > me that the timeline for its release is very behind schedule [1], but > > > still in active development. Can you give a SWAG for how close that new > > > spec is to completion? Are we months away or years? > > > > > > 2. If/when SPDX 3 support is released, is it to be assumed that the SPDX > > > facilities in OE core are going to be upgraded to handle it? > > Assuming someone does the work, which is likely, yes. We did namespace > > the class in master to prepare for that. > > > > > 3. The rest of my org is interested in CycloneDX as our common SBOM > > > format. Have there been any discussions about supporting CDX SBOMs in > > > OE-core? Any blockers there; or is it something that my org could author > > > and upstream if we decide to go that route? > > At this point OpenEmbedded/Yocto Project has decided to go the SPDX > > route for various reasons. > > Are those reasons documented somewhere? > > Something about CDX rubs me the wrong way (besides it being named like > an off-brand printer company), but I can't put my finger on what. So if > there are technical reasons that it is less desirable for the OE > usecase, I'd like to know about them.
I think I share that same feeling but it is hard to put a finger on why. I'm not sure anything was documented but there was a discussion by the TSC when we made the decision. Some rough random thoughts: * SPDX did go the extra step of becoming an ISO standard * We (as a community) have much better contacts with the SPDX community. It is a fellow Linux Foundation project. * We already were using SPDX license identifiers so this is a natural progression/alignment. * Looking at the CDX repositories and mailing lists, the discussions and contributions do look to be from a much smaller ecosystem * SPDX are interested in engaging with us, which as Joshua mentions, does have benefits. If we run into challenges, we can likely seek help. We're actively involved with 3.0 which means we can hopefully ensure it works well for us. Both specifications do encode roughly the same information so the project alignment with SPDX and the "social" aspects likely tipped the balance. > My understanding is that CDX has better support for embedding > vulnerability (+VEX) and attestation elements into its DOM, which is > something that our Aero-Def customers will be interested in. I suppose I > can build workflows to add that information after converting the OE-SPDX > document to CDX, but I'd like to integrate the whole thing into an OE > build, if possible. I think CDX added VEX information in the last year or so and SPDX plans to do so in their 3.0. I have had the feeling it is due soon. > > I'm not sure I want to see two formats being > > added directly to the core, the better solution would likely be to > > translate the SPDX output into CycloneDX if/as needed. > > I'm concerned about the lossiness of that conversion. Based on the > CDX-SPDX mapping document in the cdx2spdx tool repo [1], they seem > roughly compatible. But I haven't been able to find a clean tool which > converts the other direction, nor a mapping document for the SPDX->CDX > pathway. You could take that different ways but it could mean people aren't finding a need to convert SPDX to CDX, meaning SPDX is working for them. I don't really want to have two partially implemented SBoM mechanisms in YP/OE so I'd probably suggest any CDX code was a separate layer at this point. If there is actual missing capability, I'd be asking SPDX to resolve it :) Cheers, Richard (copying Kate Stewart to the discussion)
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#176785): https://lists.openembedded.org/g/openembedded-core/message/176785 Mute This Topic: https://lists.openembedded.org/mt/96729387/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
