Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collect data from Yocto #1468

Open
pombredanne opened this issue Apr 25, 2024 · 4 comments
Open

Collect data from Yocto #1468

pombredanne opened this issue Apr 25, 2024 · 4 comments

Comments

@rossburton
Copy link

No, The cve-exclusion_[version].inc files are generated by generate-cve-exclusions, which pulls data from https://www.linuxkernelcves.com. We're not really a source of data regarding kernel CVEs, if that's what you're after.

@pombredanne
Copy link
Member Author

@rossburton thanks!
I will be closing this in favor of this other issue that already tracks https://www.linuxkernelcves.com by @nluedtke

I also saw this repo https://github.com/yoctoproject/cve-cna-open-letter so there is some obvious problem: what data do you need exactly in Yocto/OpenEmbedded ?

I see in https://github.com/yoctoproject/poky/blob/master/meta/classes/cve-check.bbclass that the mapping between a CVE and Yocto package seems to be based on an approximate query on the name and vendor?

Could this be done better?

We could track a Yocto PURL type instead in https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst and provide here a clear mapping to Yocto's PN/PV(and then likely in other vulnerability databases)

(closely related I have an oldie but goodie branch to detect Yocto/BB packages in https://github.com/nexB/scancode-toolkit/tree/1243-bitbake )

@rossburton
Copy link

I also saw this repo https://github.com/yoctoproject/cve-cna-open-letter so there is some obvious problem: what data do you need exactly in Yocto/OpenEmbedded ?

I see in https://github.com/yoctoproject/poky/blob/master/meta/classes/cve-check.bbclass that the mapping between a CVE and Yocto package seems to be based on an approximate query on the name and vendor?

We have tooling that automatically searches the CVE database for issues with CPEs that we have recipes for, for example if we have a curl_8.7.1.bb recipe then the product is curl and version is 8.7.1. We let recipes override this where the default isn't suitable, but as a default that works well enough.

However, with the recent problems at NIST effectively zero new CVEs in the last few months have CPEs assigned, this is what the open letter is trying to encourage a resolution on.

Could this be done better?

Almost certainly!

We could track a Yocto PURL type instead in https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst and provide here a clear mapping to Yocto's PN/PV(and then likely in other vulnerability databases)

Adding Yocto seems like a sensible thing to do. The fun will be that oe-core/poky is just a reference distro, so you might want to add a 'distro name' parameter to differentiate 'pure' oe-core from arbitrary vendor's derived distributions.

@pombredanne
Copy link
Member Author

@rossburton re:

Adding Yocto seems like a sensible thing to do. The fun will be that oe-core/poky is just a reference distro, so you might want to add a 'distro name' parameter to differentiate 'pure' oe-core from arbitrary vendor's derived distributions.

This makes sense. I'll start a PR for PURL and will ping you and Richard there for review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants