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. Thank you, Andrej On Tue, 2023-05-23 at 10:41 +0200, Valek Andrej wrote: > Hello Richard, > > Could you please take a look on the latest revision a make a decision there? > There are still bunch of unclear statements. So please make a final design and > we will try to implement it. > > Thank you, > Andrej > > On Mon, 2023-05-22 at 10:57 +0300, Mikko Rapeli wrote: > > Hi, > > > > On Fri, May 19, 2023 at 03:11:57PM +0200, Marta Rybczynska wrote: > > > I'm missing a status to cover the situation when the NVD (or any other > > > database) has an incorrect entry. We have quite many of those. This might > > > be a temporary situation, but not always. > > > > > > SPDX (the 3.0 draft) has some other possible reasons > > > https://github.com/spdx/spdx-spec/blob/vulnerability-profile/chapters/profile-vulnerabilities.md > > > What looks like interesting ideas are: > > > * "Can't fix" / "Will not fix" > > > * "Not applicable" (SPDX language: Ineffective) when the code is not used > > > * "Invalid match" (this is our NVD mismatch case) > > > * "Mitigated" measures taken so that it cannot be exploited > > > * "Workarounded" > > > > To me the SPDX details don't seem very usable when actually maintaining > > a linux distro for a long time. Anyone from major Linux distro > > stable/security teams participating in the work? > > > > So I'd rather compare to Debian security tracker CVE status data and ask > > what our LTS and master branch maintainers and those in the community > > who maintain yocto based SW stacks need. Do the maintainers want to read > > SPDX output, for example? What common statuses do the maintainers want to > > encode for each CVE? > > > > Debian security tracker > > https://security-team.debian.org/security_tracker.html > > shows states: > > > > * vulnerable: binary package with specified version in their distro > > version is vulnerable to the issue > > > > * fixed: binary package in their distro version has fixed the issue > > > > * undetermined: it is not yet clear if the issue affects Debian and > > their version of the packages > > > > And "vulnerable" has sub states: > > > > * ignored: the issue does not impact Debian packages > > > > * postponed: no security patch updates will be provided, e.g. such a > > minor issue that update will happen for example via normal package > > version updates to next stable version > > > > There are a lot of additional "standards" and sub states when looking at > > CVE data in the tracker (info not public, no upstream fix available, not > > supported configuration etc), but those major high level states are enough. > > And then there are security relevant bugs without CVEs. > > > > I've been happy with "Unpatched", "Patched" and "Ignored" states for > > each CVE detected by cve-check.bbclass. There could be a few more sub > > stated to "Ignored" and the "Patched" state should better reflect reality, > > which this patch set helps. But I'm happy with that. > > > > I'm not so happy with the SPDX states names and meanings. > > > > Cheers, > > > > -Mikko >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181854): https://lists.openembedded.org/g/openembedded-core/message/181854 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] -=-=-=-=-=-=-=-=-=-=-=-
