On Thu, Jul 25, 2024 at 12:13 AM Richard Purdie < richard.pur...@linuxfoundation.org> wrote:
> 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 our case, the big part of "wontfix" is the "bdb" abandoned package. The action here would be to finish removing this dependency. I can also see some of the wontfix that can be re-qualified. > > 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). > I think it is a good idea to tag them, so that people do not re-do the whole analysis. > > > > 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? > > Under the CRA, this is the manufacturer distributing their product that is responsible. As they won't be able to release with unfixed CVEs, they will need to resolve the issue in some way (a local fix, disable a configuration option, do an analysis showing that this code will never be executed etc). Even if the upstream refuses their fix, they need to ship clean. Some minor details of the CRA might change, but the above won't - this is the main idea behind this legislation. Simply "upstream won't fix this" won't be a valid answer. We can chat about the impact on Tuesday or do a separate call if it makes sense. Kind regards, Marta
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#202538): https://lists.openembedded.org/g/openembedded-core/message/202538 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] -=-=-=-=-=-=-=-=-=-=-=-
