From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: benjamin.robin@bootlin.com, openembedded-core@lists.openembedded.org
Cc: ross.burton@arm.com, peter.marko@siemens.com,
jpewhacker@gmail.com, olivier.benjamin@bootlin.com,
antonin.godard@bootlin.com, mathieu.dubois-briand@bootlin.com,
thomas.petazzoni@bootlin.com
Subject: Re: [OE-core] [PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher
Date: Wed, 18 Mar 2026 17:45:53 +0000 [thread overview]
Message-ID: <64a1484a196d4e9c603ec6dda598c6a8c4b91606.camel@linuxfoundation.org> (raw)
In-Reply-To: <20260309-add-sbom-cve-check-p2b-v1-0-09165cddfcf1@bootlin.com>
Hi,
On Mon, 2026-03-09 at 12:57 +0100, Benjamin Robin via lists.openembedded.org wrote:
> This series is an RFC and a follow-up to patch 6/6 ("Add class for
> post-build CVE analysis"), which was previously discussed [1].
> I have prepared two RFC series, this one and another, each exploring
> different approaches to handling the download of CVE databases.
>
> I explored using BitBake's internal fetcher instead of direct Git calls
> for fetching CVE databases. However, I encountered two major issues:
>
> - No proper shallow clone support: I wanted to clone the repository
> without downloading the entire history (which is very large). While
> `BB_GIT_SHALLOW` exists, it creates multiple tarballs in the download
> directory, which is inefficient for updates.
>
> In this series, we are going to do a full clone of the git repository,
> so this point is not going to be fixed.
>
> - Performance overhead for CVE databases deployment: The recipes
> downloading CVE databases must copy them to the sysroot or to the
> deploy directory. This requires copying the extracted databases
> multiple times, even with hard links, which is slow due to the
> combined size (~6 GB, ~672,000 small files).
>
> In this series, we are using a custom deploy task that is going to
> copy the git repository using rsync directly in the final deploy
> directory, by-passing all the Bitbake logic.
>
> Additionally, there's no built-in way to control the interval between
> CVE database fetches: In this series, we are going to use AUTOREV,
> which imply to query the git repositories for each build, to check if
> there is a new git revision.
>
> Moreover, this series ensures that the CVE analysis runs only when
> the original SBOM changes or when the CVE databases are updated.
>
> Upon revisiting the class and its associated recipes, I identified
> several areas for improvement, which were fixed in the first commit.
> This series also includes a second commit making the VEX class optional
> rather than mandatory.
>
> [1] https://lore.kernel.org/all/20260226-add-sbom-cve-check-v3-0-2e60423f4d35@bootlin.com/
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.
The existing approach was only done as it was a sqlite database and we
didn't have fetcher support for such a thing. 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.
As such, I was wondering if you had never versions of these patches?
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.
Cheers,
Richard
next prev parent reply other threads:[~2026-03-18 17:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-09 11:57 [PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher Benjamin Robin
2026-03-09 11:57 ` [PATCH RFC 1/2] " Benjamin Robin
2026-03-09 11:57 ` [PATCH RFC 2/2] sbom-cve-check: VEX class is no longer mandatory Benjamin Robin
2026-03-18 17:45 ` Richard Purdie [this message]
2026-03-19 7:29 ` [OE-core] [PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher Marta Rybczynska
2026-03-19 7:52 ` Richard Purdie
2026-03-19 9:07 ` Benjamin Robin
2026-03-19 9:57 ` Benjamin Robin
2026-03-19 8:45 ` Benjamin Robin
2026-03-19 8:58 ` Marta Rybczynska
2026-03-19 9:48 ` Benjamin Robin
2026-03-19 12:00 ` Marta Rybczynska
2026-03-19 12:03 ` Benjamin Robin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64a1484a196d4e9c603ec6dda598c6a8c4b91606.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=antonin.godard@bootlin.com \
--cc=benjamin.robin@bootlin.com \
--cc=jpewhacker@gmail.com \
--cc=mathieu.dubois-briand@bootlin.com \
--cc=olivier.benjamin@bootlin.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=peter.marko@siemens.com \
--cc=ross.burton@arm.com \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox