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. 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 (#202488): https://lists.openembedded.org/g/openembedded-core/message/202488 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] -=-=-=-=-=-=-=-=-=-=-=-
