Re: [OE-core][PATCH v3 1/3] cve-check: add option to add additional patched CVEs

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

On Mon, 2023-05-29 at 07:32 +0000, Valek, Andrej wrote:
> Hello again Richard,
> 
> Maybe this email was little bit unclear..., so I will try to recap it here.
> There are 2 open points, where some final decision has to be made.
> 
> - Could we rename the CVE_STATUS_REASONING -> CVE_STATUS_REASON? The first idea
> came from you.
> - What is the final enum for CVE_STATUS? I would say "patched" and "ignored".
> Afaik, the "not applicable" status came also from you. Should we keep it, or
> remove it? Of course all others are just like an additions which could be
> implemented later on request.
> 
> So please, take a look on it and made a final decision.

Whilst it is true that I get to make a final decision on whether to
merge a patch or not (for better or worse), what we need here is a
community consensus about what we need to do. Usually that is done with
a proposal which gets tweaked until there aren't strong objections to
it and a majority are in agreement.

If do change, we need to get it right as we can't keep changing. We
also need to be mindful that the LTS releases are more closely coupled
in this area. That said, we need to get things right for master, then
work out how to work with the LTSes.

I think we're all in agreement we need to do something more than what
we currently have as it isn't scaling as we need.

FWIW I'm not sold on CVE_STATUS_REASON*, how about CVE_STATUS_DETAIL?

My original concern with "ignored" also remains. I'd really like to
encode more detail about why we think it can be ignored.

For example, this set of values would seem to match the common reasons
we see:

patched - we carry a patch meaning the CVE has been fixed

cpe-incorrect - the CPE entry versioning is incorrect and our version (and newer versions) are fixed. An update to the database is hopefully pending.

cpe-stable-backport - the CPE entry doesn't cover backports to stable series but patches are applied there (e.g. kernel LTS versions)

not-applicable-platform - the platform isn't applicable for us (e.g. windows or OS-X)

upstream-wontfix - the upstream maintainers don't believe the issue needs to be fixed

not-applicable-config - our configuration means the issue isn't enabled/present/applicable

other - CVE doesn't apply for some other reason

The reason for having these different categories is it means people can
group and act upon them differently. If you were building on windows,
you'd take a close look at the platform ones. If you were changing
kernels, you'd know cpe-stable-backport was potentially incorrect. If
you're changing PACKAGECONFIG, you'd take a closer look at not-
applicable-configuration.

I'm not 100% sure I have all the right categories but I'm trying to
articulate my own thoughts having written a number of the exclusions.
I'd be interested to understand if the above works for others. The
challenge is we all have different reasons and uses for the data.

Cheers,

Richard