On Friday, August 14, 2026 at 12:05 AM, Marko, Peter wrote: > > 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
Peter, I will be on vacation, so I won’t have time to work on this. Feel free to create a PR to add this feature. I don't know if it's possible to simply add `sbom-cve-check-recipe` to Scarthgap—I haven't checked yet—but I have some slight doubts about it (though I could be completely wrong). -- Benjamin Robin, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#243448): https://lists.openembedded.org/g/openembedded-core/message/243448 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]] -=-=-=-=-=-=-=-=-=-=-=-
