On Thu, Mar 19, 2026 at 9:45 AM Benjamin Robin via lists.openembedded.org <[email protected]> wrote:
> 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. > The CVE project repo does not have a licence included, but it is covered by https://www.cve.org/legal/termsofuse (the usage part). It is basically MIT. NVD has the specific, licence, the one that is in the repo. A warning on the needed disclosure sentence in all documentation. > > 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. > They implement the fetcher to feed into sqlite. Which was an error to use, in my opinion. > > > 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? > AUTOREV isn't great here because it will re-fetch for each build. So if you're building multiple images or platforms (in CI or so), you will get potentially different results. cve-check has a set of variable to handle such use cases. You pin to one specific release and do the whole checking with one single common version. Regards, Marta
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#233469): https://lists.openembedded.org/g/openembedded-core/message/233469 Mute This Topic: https://lists.openembedded.org/mt/118219723/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
