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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#243350):
https://lists.openembedded.org/g/openembedded-core/message/243350
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]]
-=-=-=-=-=-=-=-=-=-=-=-
