Re: [OE-core][PATCH v3 5/5] cve-extra-exclusions.inc: add deprecation notice

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2024-08-01 at 15:58 +0200, Marta Rybczynska wrote:
> On Thu, Aug 1, 2024 at 3:47 PM Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> > On Fri, 2024-07-26 at 14:28 +0200, Marta Rybczynska via
> > lists.openembedded.org wrote:
> > > On Fri, Jul 26, 2024 at 2:24 PM Ross Burton <Ross.Burton@arm.com>
> > > wrote:
> > > > On 24 Jul 2024, at 16:25, Marta Rybczynska via
> > > > lists.openembedded.org
> > > > <rybczynska=gmail.com@lists.openembedded.org> wrote:
> > > > > 
> > > > > This file contains CVE_STATUS without machine-readable
> > > > > information on which
> > > > > recipe it applies to. All entries should be verified and, if
> > > > > appropriate,
> > > > > moved to their corresponding recipes.
> > > > 
> > > > The point of this file was to be an opt-in for more exclusions
> > > > where we didn’t feel 100% confident asserting the issues could be
> > > > ignored.
> > > > 
> > > > How much of a problem is it if this file contains a a limited
> > > > number of CVEs?  We can review what is in there and move/remove as
> > > > needed to cut it down.
> > > 
> > > With the vex class (and with SPDX too, I think) they end up copied
> > > present in every single package of the build. This brings enormous
> > > confusion.
> > > Impossible to filter them out as there is no information about the
> > > affected recipe/package.
> > 
> > Difficult, yes, impossible, no.
> > 
> > Surely we know which recipes a given CVE apply to?
> 
> Without having the CVE data at the same time, no.

I thought we had the CVE data?

>  Also, a CVE might apply to multiple
> recipes at the same time - and this could be dangerous. Imagine a situation where
> the CPE is incorrect and is pointing to the wrong package. It gets added to .inc.
> But then someone in their layer adds the package the CVE really applies to...

We can't cover every possible scenario and if the data is wrong, we
identify and fix it.

> If we keep the .inc file, I think the most correct way would be to add a field marking
>  which recipe it should be applied to. 
> 
> What do you think?

How do we mark up a CVE as applying to gcc-cross-*/gcc-cross-canadian-
*/gcc-runtime/libgcc and so on?

How do we convert "bash" to "nativesdk-bash" and "bash-native"?

There are ways we could do such markup but I don't think it is going to
work well. 

I guess the key question is what we're trying to achieve and where
we're expecting the data to be processed?

Could we write a common exclusion file out once as part of the CVE
fetch recipe and avoid putting it into the individual recipe output?

Cheers,

Richard