> -----Original Message----- > From: Benjamin Robin <[email protected]> > Sent: Thursday, August 13, 2026 1:56 PM > To: Marko, Peter (FT D EU SK BFS1) <[email protected]>; > [email protected]; Paul Barker <[email protected]> > Cc: Richard Purdie <[email protected]>; Yoann Congal > <[email protected]>; Ross Burton <[email protected]> > Subject: Re: [wrynose][RFC PATCH 00/11] sbom-cve-check update > > On Thursday, August 13, 2026 at 1:46 PM, Paul Barker wrote: > > On Sat, 2026-08-08 at 12:51 +0200, Peter Marko wrote: > > > This series updates sbom-cve-check tooling in wrynose to current master. > > > Unfortunately it shows that having cve-check tooling in upstream > > > components violates LTS patch acceptance policies. > > > > > > In this case the most visible is python3-shacl2code (1.0.1 -> 1.1.0), > > > but also sbom-cve-check-update-nvd-native introduces new features > > > (which is actually the reason why this upgrade is wanted). > > > For now this should not be a big issue as all the dependencies are very > > > new and used exclusively in cve-check, however by time they may be used > > > in other recipes or tooling, too. > > > > > > So I am sending this series as RFC to discuss future of CVE checking on > > > LTS branches. > > > * should we go with this series as is (possibly updating policy text)? > > > * or are we stuck with old code for next 3.5 years? > > > * or separate the tooling to meta-sbom-cve-check which would only have > > > master branch to service all currently supported releases? > > > * or create mixins layer (to be also used by AB cve-metrics jobs)? > > > * or are there some other suggestions how to rework this series? > > > > > > My preference would be to have cve-check aligned for all supported > > > releases (even scarthgap), so I would welcome opinions and discussion > > > on this topic. > > Hello Peter, > > Thank you for taking the time to create this series. I had been planning > to work on it, but I was a bit busy :) > > > > > Hi Peter, > > > > The TSC has discussed this series and is happy for sbom-cve-check to be > > updated on wrynose. It's in line with the expectations we had when > > wrynose was released, and the upstream maintainer is involved. > > > > For scarthgap it's a different question. That still has the > > cve-check.bbclass implementation instead of sbom-cve-check, this would > > be whole new framework rather than a set of updates. I wonder if this > > can be handled via an LTS mixin layer instead of a backport in OE-core?
Paul, as the meta-sbom-cve-check layer shows, sbom-cve-check can co-exist with the old cve-check. It does not have to be the super-invasive with breaking change. So in theory it should be pretty easy to copy 3 classes and bunch of support recipes. But I'm also fine with having an external layer for that. Question is if Yocto project would also switch cve-metrics to the sbom-cve-check. That would of course highly increase the open CVE numbers but would also help identify missing CVE fixes. > > Hello Paul, > > Technically, I think we could backport sbom-cve-check to scarthgap, but > indeed it still has the cve-check.bbclass implementation. > > sbom-cve-check can be run outside of Yocto, but if you want it integrated > into Yocto, there's already a layer for that: > https://github.com/bootlin/meta-sbom-cve-check Benjamin, This is super cool. However, cve-metrics uses sbom-cve-check-recipe, which is not part of this layer. When updating, please consider adding it. Peter > > However, I need to update it to version 1.3.3. > > -- > Benjamin Robin, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#243390): https://lists.openembedded.org/g/openembedded-core/message/243390 Mute This Topic: https://lists.openembedded.org/mt/120655242/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
