Hello Marta, On Thursday, March 19, 2026 at 9:58 AM, Marta Rybczynska wrote: > On Thu, Mar 19, 2026 at 9:45 AM Benjamin Robin via lists.openembedded.org > <[email protected]> wrote:
> > 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. So for you, it is fine to declare that the CVE databases are MIT? > > 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. Well, I understand why they did that. It makes a lot of sense. But it has a lot of limitation, that is why we developed sbom-cve-check. > 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. Yes, that is why I initially pushed to use my custom fetcher that is doing a git pull / shallow clone. With this fetcher I have a full control on the update period. But if we want to use BitBake fetcher, an user could pin to a specific version instead of using AUTOREV. But the user needs to to that manually. -- Benjamin Robin, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#233473): https://lists.openembedded.org/g/openembedded-core/message/233473 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]] -=-=-=-=-=-=-=-=-=-=-=-
