On Fri, Feb 3, 2023 at 12:26 PM Alex Stewart <alex.stew...@ni.com> 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?
Our goal is to provide SPDX 3.0 with "example" SPDX 3.0 documents before the initial release. This should benefit both projects, since it means that we can give SPDX real examples of comprehensive SBoMs before they release the 3.0 spec, and also means that Yocto project SPDX output should be of high quality. SPDX 3.0 is moving along and it's getting closer to release, but I can't say exactly when the release will be. If you have serious interest in this, I would recommend joining the SPDX meetings: https://github.com/spdx/meetings/blob/main/README.md > > 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? Yes. We should have support for generating either the current SPDX 2.2, or SPDX 3.0 > > 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? As stated, we don't really think supporting CycloneDX is worth our effort in the project. That effort would probably be better spent making the conversion tools better. There's not really any documentation why we made this choice, I just decided to do it this way when I wrote the implementation. TBH I think both formats are technically fine, but SPDX had an edge because of the LF connection between the two projects. Gvien that there are conversion tools between them, I wasn't really concerned that choosing one format of the other would cause problems. > > > [1] https://github.com/spdx/spdx-spec/milestone/3 > > > Appreciate the input, > > -- > Alex Stewart > Software Engineer - NI Real-Time OS > NI (National Instruments) > > alex.stew...@ni.com >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#176784): https://lists.openembedded.org/g/openembedded-core/message/176784 Mute This Topic: https://lists.openembedded.org/mt/96729387/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
