Re: [wrynose][RFC PATCH 00/11] sbom-cve-check update

[Benjamin Robin <benjamin.robin@bootlin.com>]

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?

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                                                                                                                                                                                                                                                                         
                                                                                                                                                                                                                                                                                                                            
However, I need to update it to version 1.3.3.

-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com