>-----Original Message----- >From: Richard Purdie <richard.pur...@linuxfoundation.org> >Sent: Thursday, July 25, 2024 3:44 AM >To: Marta Rybczynska <rybczyn...@gmail.com> >Cc: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) ><dnago...@cisco.com>; Marko, Peter <peter.ma...@siemens.com>; >openembedded-core@lists.openembedded.org; xe-linux-external(mailer list) ><xe-linux-exter...@cisco.com> >Subject: Re: [OE-core] [PATCH] cve-check-map: Move 'upstream-wontfix' to >"Unpatched" status > >On Wed, 2024-07-24 at 18:10 +0200, Marta Rybczynska wrote: >> On Wed, Jul 24, 2024 at 10:46 AM Richard Purdie via lists.openembedded.org ><richard.purdie=linuxfoundation....@lists.openembedded.org> wrote: >> > >> > 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. > >I'm working on the assumption that if either of those two things were the case, >we'd have done them in preference to the wontfix status. The wontfix status is >the last resort where upstream disagrees there is an issue or that the issue is >an actual problem.
As per my understanding, we have 'disputed' status for the above mentioned scenarios. (Where upstream disagrees, or they don't consider issue a problem) Below is the snippet from the current cve-check-map.conf # use when upstream does not accept the report as a vulnerability (e.g. works as designed) CVE_CHECK_STATUSMAP[disputed] = "Ignored" # use when upstream *acknowledged* the vulnerability but does not plan to fix it CVE_CHECK_STATUSMAP[upstream-wontfix] = "Ignored" > >In those situations, there isn't much we can do. The status is spelt out >separately so anyone wanting to find this "class" of problems can. >How they want to map and export that into lossy formats is up to the user and >configurable. > >The only "decision" we're making is that we won't show that status as "open" >on our standard lists as someone has looked at it and decided there isn't >anything to be done (or can 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. >> > >> >> >> 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'. > >Your argument appears to be that we aren't in a position to make any decision >on the status of any CVE and we can't share this work, it has to be pushed to >the end user to do on their own and the CRM mandates that? > >I don't believe that to be true but that does appear to be the case you're >making :(. > >Cheers, > >Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#202493): https://lists.openembedded.org/g/openembedded-core/message/202493 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] -=-=-=-=-=-=-=-=-=-=-=-
