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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181911): https://lists.openembedded.org/g/openembedded-core/message/181911 Mute This Topic: https://lists.openembedded.org/mt/99007092/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
