RE: [OE-core][PATCH v3 1/5] cve-check: annotate CVEs during analysis

["Marko, Peter" <Peter.Marko@siemens.com>]

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of Richard Purdie via
> lists.openembedded.org
> Sent: Thursday, August 1, 2024 15:45
> To: rybczynska@gmail.com; openembedded-core@lists.openembedded.org
> Cc: Marta Rybczynska <marta.rybczynska@syslinbit.com>; Samantha Jalabert
> <samantha.jalabert@syslinbit.com>
> Subject: Re: [OE-core][PATCH v3 1/5] cve-check: annotate CVEs during
> analysis
> 
> On Wed, 2024-07-24 at 17:25 +0200, Marta Rybczynska via
> lists.openembedded.org wrote:
> > Add status information for each CVE under analysis.
> >
> > Previously the information passed between different function of the
> > cve-check class included only tables of patched, unpatched, ignored
> > vulnerabilities and the general status of the recipe.
> >
> > The VEX work requires more information, and we need to pass them
> > between different functions, so that it can be enriched as the
> > analysis progresses. Instead of multiple tables, use a single one with
> > annotations for each CVE encountered. For example, a patched CVE will
> > have:
> >
> > {"abbrev-status": "Patched", "status": "version-not-in-range"}
> >
> > abbrev-status contains the general status (Patched, Unpatched, Ignored
> > and Unknown that will be added in the VEX code) status contains more
> > detailed information that can come from CVE_STATUS and the analysis.
> >
> > Additional fields of the annotation include for example the name of
> > the patch file fixing a given CVE.
> >
> > The side-effect of this change is that all entries from CVE_STATUS are
> > available in the result file. That includes entries from the optional
> > file cve-extra-exclusions.inc even if they might have no link with the
> > recipe (apply to a different package). This will be fixed by moving
> > all entries from that file to appropriate recipes.
> >
> > From now on, CVE_STATUS should be added directly in the recipe file or
> > in include files added only to affected recipes.
> 
> Sorry about the delay in getting to this. Initially I thought things were ok but
> now I understand what is happening here, I'm afraid I have concerns.
> 
> A fundamental property of what we're offering that we can use a common
> include file to inject CVE_STATUS entries for recipes. Whilst I can understand
> some of the concerns about the existing .inc file, we are never going to be in a
> position where all users agree on exactly what we should do with all CVEs.
> 
> The alternative is requiring a bbappend per recipe every time some
> distro/company wants to add an entry and this is clearly not a good solution.

I wonder if can could add optional cpe product for which the ignored entry is targeted?
Something like converting first line of the general exclusion list to:
CVE_STATUS[CVE-2000-0006,strace] = ...
CVE_STATUS[CVE-2000-0006,linux_kernel] = ...

> 
> I'm afraid I'm therefore very much against mandating that CVE_STATUS entries
> should be against individual recipes. We need to find a different solution rather
> than requiring that. We can likely sort the file in core but not in other people's
> layers.
> 
> Cheers,
> 
> Richard