>-----Original Message----- >From: Marko, Peter <peter.ma...@siemens.com> >Sent: Wednesday, July 24, 2024 12:04 PM >To: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) ><dnago...@cisco.com>; openembedded-core@lists.openembedded.org >Cc: xe-linux-external(mailer list) <xe-linux-exter...@cisco.com> >Subject: RE: [OE-core] [PATCH] cve-check-map: Move 'upstream-wontfix' to >"Unpatched" status > >-----Original Message----- >From: openembedded-core@lists.openembedded.org <openembedded- >c...@lists.openembedded.org> On Behalf Of Dhairya Nagodra via >lists.openembedded.org >Sent: Wednesday, July 24, 2024 6:45 >To: openembedded-core@lists.openembedded.org >Cc: xe-linux-exter...@cisco.com; Dhairya Nagodra <dnago...@cisco.com> >Subject: [OE-core] [PATCH] cve-check-map: Move 'upstream-wontfix' to >"Unpatched" status > >> - The 'upstream-wontfix' is to be used when the CVE is accepted by the >> upstream, but they are not planning to fix it. >> - If the version used in Yocto is vulnerable, it should not have >> "Ignored" status. The package is still exploitable by the CVE. >> - Also, when the status is exported out of the SDK, it would be >> incorrect to put it under Ignored catgory. > >The purpose of this entry is to remove meaningless CVEs from reports so that >users don't spend countless hours over and over again on analyzing "open" >CVEs if they were already closed upstream.
I understand the need to remove the meaningless CVEs from the report and prevention of re-analysing the CVEs. And for that exact reason we have the CVE_STATUS, the CVEs would be reported as vulnerable or "open" yes, but the previous analysis would also be present in CVE_STATUS. This should give the context to the person and not requiring them to re-analyse the CVE. Also, I would re-iterate the point that when the status of CVEs is exported out of the SDK, they would be falsely reported under 'Ignored' category. >If you look at comments of entries using this category (7 in oe-core scarthgap) >these CVEs are more or less irrelevant. > >So this patch is from my point of view step in the wrong direction. >If you really need to show these due to your CVE handling process, you can >easily override this variable assignment in your own layer. > >> >> Signed-off-by: Dhairya Nagodra <dnago...@cisco.com> >> --- >> meta/conf/cve-check-map.conf | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/meta/conf/cve-check-map.conf >> b/meta/conf/cve-check-map.conf index b9df41a6f3..7ff53f5601 100644 >> --- a/meta/conf/cve-check-map.conf >> +++ b/meta/conf/cve-check-map.conf >> @@ -15,6 +15,8 @@ CVE_CHECK_STATUSMAP[unpatched] = "Unpatched" >> CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched" >> # use when CVE fix is not compatible to the current version and cannot be >backported. >> CVE_CHECK_STATUSMAP[cannot-backport] = "Unpatched" >> +# use when upstream acknowledged the vulnerability but does not plan >> +to fix it CVE_CHECK_STATUSMAP[upstream-wontfix] = "Unpatched" >> >> # used for migration from old concept, do not use for new >> vulnerabilities CVE_CHECK_STATUSMAP[ignored] = "Ignored" >> @@ -26,5 +28,3 @@ CVE_CHECK_STATUSMAP[disputed] = "Ignored" >> CVE_CHECK_STATUSMAP[not-applicable-config] = "Ignored" >> # use when vulnerability affects other platform (e.g. Windows or >> Debian) CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored" >> -# use when upstream acknowledged the vulnerability but does not plan >> to fix it -CVE_CHECK_STATUSMAP[upstream-wontfix] = "Ignored"
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#202429): https://lists.openembedded.org/g/openembedded-core/message/202429 Mute This Topic: https://lists.openembedded.org/mt/107518628/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
