On Wed, Jul 24, 2024 at 10:46 AM Richard Purdie via lists.openembedded.org <richard.purdie=linuxfoundation....@lists.openembedded.org> wrote:
> 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. > I agree and also agree with Dhairya. We are facing the same issue within the VEX work. And this is going to come back in the context of the CRA. > > 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. > The project might have decided not to fix for multiple reasons. Some of them may be good, some not. I do not completely agree that there is nothing to be done. We might decide to use a configuration option that disables the vulnerable feature. In this case there is an appropriate status to put. We can do an in-depth analysis and figure out if the vulnerable code can be reached in our configuration. If not, there is an appropriate status to put. > > 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. > I think the problem here is that we had used the "Ignored" status for multiple reasons in the past, also to avoid having a look multiple times at the same issue. Again, the CRA is formal here, and downstreams will need to re-analyse all those issues (or disable affected recipes). Either downstreams, or we will do it all together.... (which is a better option IMO). There's the same issue with some other statuses like 'disputed'. Kind regards, Marta
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#202463): https://lists.openembedded.org/g/openembedded-core/message/202463 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] -=-=-=-=-=-=-=-=-=-=-=-
