Collect data from Yocto

[pombredanne]

These are useful qualifiers on kernel CVEs:

See:

• https://github.com/openembedded/openembedded-core/blob/master/meta/conf/distro/include/cve-extra-exclusions.inc
• https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-kernel/linux/cve-exclusion.inc
• https://github.com/openembedded/openembedded-core/blob/7ef767d84d56b25498e45db83bb8f9d9caebeaf9/meta/recipes-kernel/linux/cve-exclusion_6.6.inc
• https://github.com/openembedded/openembedded-core/blob/7ef767d84d56b25498e45db83bb8f9d9caebeaf9/meta/recipes-kernel/linux/generate-cve-exclusions.py#L4

@rossburton just curious... do you create this data entirely by hand?

[rossburton]

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]

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

• https://github.com/nexB/vulnerablecode/issues/564

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]

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]

@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.