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