Re: [OE-core] [PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher

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

Hello Richard,

On Wednesday, March 18, 2026 at 6:45 PM, Richard Purdie wrote:
> I've just been trying to work out where we're at with this coming up to
> release and we need to get this resolved.
> 
> I feel quite strongly that we need to use the fetcher for obtaining
> this data. "fetching" isn't trivial and is full of
> license/auditing/sbom issues. Making any exception to that, even for
> cve data tends to become problematic later.

I have just a slight implementation "detail" if we are using BitBake
fetcher. What is the license that we should use for the sources?
How to declare that in the recipes?

Because the license of the repositories:
 - https://github.com/CVEProject/cvelistV5 : Their is none
 - https://github.com/fkie-cad/nvd-json-data-feeds/tree/main/LICENSES
   It looks like custom license.

cve-update-db-native.bb is specifying MIT but this is kind of a lie.
I have done the same on my recipes for now...
 
> The existing approach was only done as it was a sqlite database and we
> didn't have fetcher support for such a thing.

The recipes used to download the CVE databases for the cve-check class
are downloading tarballs. Yes these recipes are going to create a sqlite
database from that. But these recipes implements there own fetcher to
simply download a tarball.
That is why I thought I could implement my own fetcher, which is way
simpler than the update_db_file() in cve-update-db-native.bb which is
quite complex.

> If we need to improve the
> git fetcher in some way to better support this use case (e.g. shallow
> clone update efficiency), that is something we can work on.

Well that was my plan, but for the LTS release this was going to be too
short. So in the meantime I preferred to used a custom fetcher which
was implemented in the other RFC (or in the v4 of the original series).

> As such, I was wondering if you had never versions of these patches?

I sent 2 RFCs, one using my own fetcher, and one using the internal
fetcher (this series). And I sent a v4 of the original series.

> I'd note that we can't set AUTOREV by default, we'll need to specify a
> revision, and document how the user can enable AUTOREV in their config
> (maybe even a config fragment?). Whilst it is annoying to do that, it
> is a requirement that the system doesn't touch the network outside
> mirrors unless configured to.

If we can't use AUTOREV by default, which I understand, a config fragment
is the way to go (I think), with sane default to enable sbom-cve-check.
If the user want specific configuration, they can create their own
configuration. The config fragment would set:
 - IMAGE_CLASSES += "sbom-cve-check"
 - SRCREV:pn-sbom-cve-check-update-nvd-native = "${AUTOREV}"
 - SRCREV:pn-sbom-cve-check-update-cvelist-native = "${AUTOREV}"
 - SPDX_INCLUDE_VEX = "all"
 - SPDX_INCLUDE_COMPILED_SOURCES:pn-linux-yocto = "1"

Also, what do you think about the deployment of the CVE databases
done using rsync? Do you have a better idea?

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