On Wed, 2024-07-24 at 06:51 +0000, Dhairya Nagodra via lists.openembedded.org wrote: > > > > -----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.
This is far from straightforward unfortunately. Some people are using these lists as "are there any issues we need to worry about?". In that context, if an upstream has assessed a CVE and decided nothing need be done about it, our decision to "ignore" it is correct as there is nothing to be done. On the other hand, the CVE is open and unpatched, so listing it as unmitigated is also correct in some senses. The problem is that there is no planned way of moving forward with the CVE, so it will sit in a list of other "unpatched" CVEs and this dilutes the value of the list as you can't tell which ones are being rejected by upstream as wontfix and which ones are real and need attention. We knew that people would have different views and needs on how to handle this, which is precisely why the mapping variables exist. You can certainly configure this according to your needs and this may be a case where you'd need to do that as there isn't going to be a 100% right answer we can have. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#202430): https://lists.openembedded.org/g/openembedded-core/message/202430 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] -=-=-=-=-=-=-=-=-=-=-=-
