| Message ID | 20240724044505.3345411-1-dnagodra@cisco.com |
|---|---|
| State | New |
| Headers | show |
| Series | cve-check-map: Move 'upstream-wontfix' to "Unpatched" status | expand |
-----Original Message----- From: openembedded-core@lists.openembedded.org <openembedded-core@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-external@cisco.com; Dhairya Nagodra <dnagodra@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. If you look at comments of entries using this category (7 in oe-core scarthgap) these CVEs are more or less irrelevant. So this patch is from my point of view step in the wrong direction. If you really need to show these due to your CVE handling process, you can easily override this variable assignment in your own layer. > > Signed-off-by: Dhairya Nagodra <dnagodra@cisco.com> > --- > meta/conf/cve-check-map.conf | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/meta/conf/cve-check-map.conf b/meta/conf/cve-check-map.conf > index b9df41a6f3..7ff53f5601 100644 > --- a/meta/conf/cve-check-map.conf > +++ b/meta/conf/cve-check-map.conf > @@ -15,6 +15,8 @@ CVE_CHECK_STATUSMAP[unpatched] = "Unpatched" > CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched" > # use when CVE fix is not compatible to the current version and cannot be backported. > CVE_CHECK_STATUSMAP[cannot-backport] = "Unpatched" > +# use when upstream acknowledged the vulnerability but does not plan to fix it > +CVE_CHECK_STATUSMAP[upstream-wontfix] = "Unpatched" > > # used for migration from old concept, do not use for new vulnerabilities > CVE_CHECK_STATUSMAP[ignored] = "Ignored" > @@ -26,5 +28,3 @@ CVE_CHECK_STATUSMAP[disputed] = "Ignored" > CVE_CHECK_STATUSMAP[not-applicable-config] = "Ignored" > # use when vulnerability affects other platform (e.g. Windows or Debian) > CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored" > -# use when upstream acknowledged the vulnerability but does not plan to fix it > -CVE_CHECK_STATUSMAP[upstream-wontfix] = "Ignored"
>-----Original Message----- >From: Marko, Peter <Peter.Marko@siemens.com> >Sent: Wednesday, July 24, 2024 12:04 PM >To: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) ><dnagodra@cisco.com>; openembedded-core@lists.openembedded.org >Cc: xe-linux-external(mailer list) <xe-linux-external@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- >core@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-external@cisco.com; Dhairya Nagodra <dnagodra@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. >If you look at comments of entries using this category (7 in oe-core scarthgap) >these CVEs are more or less irrelevant. > >So this patch is from my point of view step in the wrong direction. >If you really need to show these due to your CVE handling process, you can >easily override this variable assignment in your own layer. > >> >> Signed-off-by: Dhairya Nagodra <dnagodra@cisco.com> >> --- >> meta/conf/cve-check-map.conf | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/meta/conf/cve-check-map.conf >> b/meta/conf/cve-check-map.conf index b9df41a6f3..7ff53f5601 100644 >> --- a/meta/conf/cve-check-map.conf >> +++ b/meta/conf/cve-check-map.conf >> @@ -15,6 +15,8 @@ CVE_CHECK_STATUSMAP[unpatched] = "Unpatched" >> CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched" >> # use when CVE fix is not compatible to the current version and cannot be >backported. >> CVE_CHECK_STATUSMAP[cannot-backport] = "Unpatched" >> +# use when upstream acknowledged the vulnerability but does not plan >> +to fix it CVE_CHECK_STATUSMAP[upstream-wontfix] = "Unpatched" >> >> # used for migration from old concept, do not use for new >> vulnerabilities CVE_CHECK_STATUSMAP[ignored] = "Ignored" >> @@ -26,5 +28,3 @@ CVE_CHECK_STATUSMAP[disputed] = "Ignored" >> CVE_CHECK_STATUSMAP[not-applicable-config] = "Ignored" >> # use when vulnerability affects other platform (e.g. Windows or >> Debian) CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored" >> -# use when upstream acknowledged the vulnerability but does not plan >> to fix it -CVE_CHECK_STATUSMAP[upstream-wontfix] = "Ignored"
On Wed, 2024-07-24 at 06:51 +0000, Dhairya Nagodra via lists.openembedded.org wrote: > > > > -----Original Message----- > > From: Marko, Peter <Peter.Marko@siemens.com> > > Sent: Wednesday, July 24, 2024 12:04 PM > > To: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) > > <dnagodra@cisco.com>; openembedded-core@lists.openembedded.org > > Cc: xe-linux-external(mailer list) <xe-linux-external@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- > > core@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-external@cisco.com; Dhairya Nagodra <dnagodra@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
On Wed, Jul 24, 2024 at 10:46 AM Richard Purdie via lists.openembedded.org <richard.purdie=linuxfoundation.org@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.Marko@siemens.com> > > > Sent: Wednesday, July 24, 2024 12:04 PM > > > To: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) > > > <dnagodra@cisco.com>; openembedded-core@lists.openembedded.org > > > Cc: xe-linux-external(mailer list) <xe-linux-external@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- > > > core@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-external@cisco.com; Dhairya Nagodra <dnagodra@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
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.org@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
>-----Original Message----- >From: Richard Purdie <richard.purdie@linuxfoundation.org> >Sent: Thursday, July 25, 2024 3:44 AM >To: Marta Rybczynska <rybczynska@gmail.com> >Cc: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) ><dnagodra@cisco.com>; Marko, Peter <Peter.Marko@siemens.com>; >openembedded-core@lists.openembedded.org; xe-linux-external(mailer list) ><xe-linux-external@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.org@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
On Thu, Jul 25, 2024 at 12:13 AM Richard Purdie < richard.purdie@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.org@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
On Thu, Jul 25, 2024 at 7:50 AM Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) <dnagodra@cisco.com> wrote: > > > >-----Original Message----- > >From: Richard Purdie <richard.purdie@linuxfoundation.org> > >Sent: Thursday, July 25, 2024 3:44 AM > >To: Marta Rybczynska <rybczynska@gmail.com> > >Cc: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) > ><dnagodra@cisco.com>; Marko, Peter <Peter.Marko@siemens.com>; > >openembedded-core@lists.openembedded.org; xe-linux-external(mailer list) > ><xe-linux-external@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.org@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" > upstream-wontfix and disputed is far from the same thing at the CVE Programme level. "disputed" is a flag of the CVE entry (at least for the most recent ones) and it will be possible to attach it automatically. However, it still means a vendor analysis is needed to decide which side of the dispute you agree with... Kind regards, Marta
>-----Original Message----- >From: Marko, Peter <Peter.Marko@siemens.com> >Sent: Wednesday, July 24, 2024 12:04 PM >To: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) ><dnagodra@cisco.com>; openembedded-core@lists.openembedded.org >Cc: xe-linux-external(mailer list) <xe-linux-external@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- >core@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-external@cisco.com; Dhairya Nagodra <dnagodra@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. >If you look at comments of entries using this category (7 in oe-core scarthgap) >these CVEs are more or less irrelevant. > >So this patch is from my point of view step in the wrong direction. >If you really need to show these due to your CVE handling process, you can >easily override this variable assignment in your own layer. > I tried this in my layer, created a .conf and included in my distro.conf file. The issue is, it gets overwritten by cve-check-map.conf (as it is included later). Would it be okay to make assignments soft in the cve-check-map.conf file? This would be similar to CVE_PRODUCT and CVE_VERSION. If everyone agrees, I can share the patch for it. Is there a better way to do this? Best Regards, Dhairya >> >> Signed-off-by: Dhairya Nagodra <dnagodra@cisco.com> >> --- >> meta/conf/cve-check-map.conf | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/meta/conf/cve-check-map.conf >> b/meta/conf/cve-check-map.conf index b9df41a6f3..7ff53f5601 100644 >> --- a/meta/conf/cve-check-map.conf >> +++ b/meta/conf/cve-check-map.conf >> @@ -15,6 +15,8 @@ CVE_CHECK_STATUSMAP[unpatched] = "Unpatched" >> CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched" >> # use when CVE fix is not compatible to the current version and cannot be >backported. >> CVE_CHECK_STATUSMAP[cannot-backport] = "Unpatched" >> +# use when upstream acknowledged the vulnerability but does not plan >> +to fix it CVE_CHECK_STATUSMAP[upstream-wontfix] = "Unpatched" >> >> # used for migration from old concept, do not use for new >> vulnerabilities CVE_CHECK_STATUSMAP[ignored] = "Ignored" >> @@ -26,5 +28,3 @@ CVE_CHECK_STATUSMAP[disputed] = "Ignored" >> CVE_CHECK_STATUSMAP[not-applicable-config] = "Ignored" >> # use when vulnerability affects other platform (e.g. Windows or >> Debian) CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored" >> -# use when upstream acknowledged the vulnerability but does not plan >> to fix it -CVE_CHECK_STATUSMAP[upstream-wontfix] = "Ignored"
> -----Original Message----- > From: Dhairya Nagodra -X (dnagodra - E INFOCHIPS LIMITED at Cisco) > <dnagodra@cisco.com> > Sent: Wednesday, August 7, 2024 12:17 > To: Marko, Peter (ADV D EU SK BFS1) <Peter.Marko@siemens.com>; Richard > Purdie <richard.purdie@linuxfoundation.org>; Marta Rybczynska > <rybczynska@gmail.com>; openembedded-core@lists.openembedded.org > Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com> > Subject: RE: [OE-core] [PATCH] cve-check-map: Move 'upstream-wontfix' to > "Unpatched" status > > > > >-----Original Message----- > >From: Marko, Peter <Peter.Marko@siemens.com> > >Sent: Wednesday, July 24, 2024 12:04 PM > >To: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) > ><dnagodra@cisco.com>; openembedded-core@lists.openembedded.org > >Cc: xe-linux-external(mailer list) <xe-linux-external@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- > >core@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-external@cisco.com; Dhairya Nagodra <dnagodra@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. > >If you look at comments of entries using this category (7 in oe-core > scarthgap) > >these CVEs are more or less irrelevant. > > > >So this patch is from my point of view step in the wrong direction. > >If you really need to show these due to your CVE handling process, you can > >easily override this variable assignment in your own layer. > > > > > I tried this in my layer, created a .conf and included in my distro.conf file. > The issue is, it gets overwritten by cve-check-map.conf (as it is included later). If you create meta-<your-layer>/conf/cve-check-map.conf it will be included instead of the one from oe-core/poky. > > Would it be okay to make assignments soft in the cve-check-map.conf file? > This would be similar to CVE_PRODUCT and CVE_VERSION. > If everyone agrees, I can share the patch for it. > Is there a better way to do this? This is also an option; I'm not opinionated on this one... > > Best Regards, > Dhairya > > > >> > >> Signed-off-by: Dhairya Nagodra <dnagodra@cisco.com> > >> --- > >> meta/conf/cve-check-map.conf | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/meta/conf/cve-check-map.conf > >> b/meta/conf/cve-check-map.conf index b9df41a6f3..7ff53f5601 100644 > >> --- a/meta/conf/cve-check-map.conf > >> +++ b/meta/conf/cve-check-map.conf > >> @@ -15,6 +15,8 @@ CVE_CHECK_STATUSMAP[unpatched] = "Unpatched" > >> CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched" > >> # use when CVE fix is not compatible to the current version and cannot be > >backported. > >> CVE_CHECK_STATUSMAP[cannot-backport] = "Unpatched" > >> +# use when upstream acknowledged the vulnerability but does not plan > >> +to fix it CVE_CHECK_STATUSMAP[upstream-wontfix] = "Unpatched" > >> > >> # used for migration from old concept, do not use for new > >> vulnerabilities CVE_CHECK_STATUSMAP[ignored] = "Ignored" > >> @@ -26,5 +28,3 @@ CVE_CHECK_STATUSMAP[disputed] = "Ignored" > >> CVE_CHECK_STATUSMAP[not-applicable-config] = "Ignored" > >> # use when vulnerability affects other platform (e.g. Windows or > >> Debian) CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored" > >> -# use when upstream acknowledged the vulnerability but does not plan > >> to fix it -CVE_CHECK_STATUSMAP[upstream-wontfix] = "Ignored"
>-----Original Message----- >From: Marko, Peter <Peter.Marko@siemens.com> >Sent: Wednesday, August 7, 2024 4:04 PM >To: Dhairya Nagodra -X (dnagodra - E INFOCHIPS LIMITED at Cisco) ><dnagodra@cisco.com>; Richard Purdie <richard.purdie@linuxfoundation.org>; >Marta Rybczynska <rybczynska@gmail.com>; openembedded- >core@lists.openembedded.org >Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com> >Subject: RE: [OE-core] [PATCH] cve-check-map: Move 'upstream-wontfix' to >"Unpatched" status > > > >> -----Original Message----- >> From: Dhairya Nagodra -X (dnagodra - E INFOCHIPS LIMITED at Cisco) >> <dnagodra@cisco.com> >> Sent: Wednesday, August 7, 2024 12:17 >> To: Marko, Peter (ADV D EU SK BFS1) <Peter.Marko@siemens.com>; Richard >> Purdie <richard.purdie@linuxfoundation.org>; Marta Rybczynska >> <rybczynska@gmail.com>; openembedded-core@lists.openembedded.org >> Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com> >> Subject: RE: [OE-core] [PATCH] cve-check-map: Move 'upstream-wontfix' >> to "Unpatched" status >> >> >> >> >-----Original Message----- >> >From: Marko, Peter <Peter.Marko@siemens.com> >> >Sent: Wednesday, July 24, 2024 12:04 PM >> >To: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) >> ><dnagodra@cisco.com>; openembedded-core@lists.openembedded.org >> >Cc: xe-linux-external(mailer list) <xe-linux-external@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- >> >core@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-external@cisco.com; Dhairya Nagodra <dnagodra@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. >> >If you look at comments of entries using this category (7 in oe-core >> scarthgap) >> >these CVEs are more or less irrelevant. >> > >> >So this patch is from my point of view step in the wrong direction. >> >If you really need to show these due to your CVE handling process, >> >you can easily override this variable assignment in your own layer. >> > >> >> >> I tried this in my layer, created a .conf and included in my distro.conf file. >> The issue is, it gets overwritten by cve-check-map.conf (as it is included >later). > >If you create meta-<your-layer>/conf/cve-check-map.conf it will be included >instead of the one from oe-core/poky. > I tried this approach, it included both of the files, and my config was over written. # <path>/distro/openembedded-core/../my-layer/conf/distro/my-cve-check-map.conf # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/defaultsetup.conf includes: # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/default-providers.inc # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/default-versions.inc # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/default-distrovars.inc # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/maintainers.inc # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/tcmode-default.inc # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/tclibc-glibc.inc # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/uninative-flags.inc # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/init-manager-none.inc # <path>/distro/openembedded-core/../openembedded-core/meta/conf/documentation.conf # <path>/distro/openembedded-core/../openembedded-core/meta/conf/licenses.conf # <path>/distro/openembedded-core/../openembedded-core/meta/conf/sanity.conf # <path>/distro/openembedded-core/../openembedded-core/meta/conf/cve-check-map.conf >> >> Would it be okay to make assignments soft in the cve-check-map.conf file? >> This would be similar to CVE_PRODUCT and CVE_VERSION. This seems to be the only way, I'll share the patch soon. >> If everyone agrees, I can share the patch for it. >> Is there a better way to do this? > >This is also an option; I'm not opinionated on this one... > >> >> Best Regards, >> Dhairya >> >> >> >> >> >> Signed-off-by: Dhairya Nagodra <dnagodra@cisco.com> >> >> --- >> >> meta/conf/cve-check-map.conf | 4 ++-- >> >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> >> >> diff --git a/meta/conf/cve-check-map.conf >> >> b/meta/conf/cve-check-map.conf index b9df41a6f3..7ff53f5601 100644 >> >> --- a/meta/conf/cve-check-map.conf >> >> +++ b/meta/conf/cve-check-map.conf >> >> @@ -15,6 +15,8 @@ CVE_CHECK_STATUSMAP[unpatched] = >"Unpatched" >> >> CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched" >> >> # use when CVE fix is not compatible to the current version and >> >> cannot be >> >backported. >> >> CVE_CHECK_STATUSMAP[cannot-backport] = "Unpatched" >> >> +# use when upstream acknowledged the vulnerability but does not >> >> +plan to fix it CVE_CHECK_STATUSMAP[upstream-wontfix] = "Unpatched" >> >> >> >> # used for migration from old concept, do not use for new >> >> vulnerabilities CVE_CHECK_STATUSMAP[ignored] = "Ignored" >> >> @@ -26,5 +28,3 @@ CVE_CHECK_STATUSMAP[disputed] = "Ignored" >> >> CVE_CHECK_STATUSMAP[not-applicable-config] = "Ignored" >> >> # use when vulnerability affects other platform (e.g. Windows or >> >> Debian) CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored" >> >> -# use when upstream acknowledged the vulnerability but does not >> >> plan to fix it -CVE_CHECK_STATUSMAP[upstream-wontfix] = "Ignored"
On Mon, 2024-08-12 at 10:08 +0000, Dhairya Nagodra -X (dnagodra - E INFOCHIPS LIMITED at Cisco) wrote: > > > > -----Original Message----- > > From: Marko, Peter <Peter.Marko@siemens.com> > > Sent: Wednesday, August 7, 2024 4:04 PM > > To: Dhairya Nagodra -X (dnagodra - E INFOCHIPS LIMITED at Cisco) > > <dnagodra@cisco.com>; Richard Purdie <richard.purdie@linuxfoundation.org>; > > Marta Rybczynska <rybczynska@gmail.com>; openembedded- > > core@lists.openembedded.org > > Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com> > > Subject: RE: [OE-core] [PATCH] cve-check-map: Move 'upstream-wontfix' to > > "Unpatched" status > > > > > > > > > -----Original Message----- > > > From: Dhairya Nagodra -X (dnagodra - E INFOCHIPS LIMITED at Cisco) > > > <dnagodra@cisco.com> > > > Sent: Wednesday, August 7, 2024 12:17 > > > To: Marko, Peter (ADV D EU SK BFS1) <Peter.Marko@siemens.com>; Richard > > > Purdie <richard.purdie@linuxfoundation.org>; Marta Rybczynska > > > <rybczynska@gmail.com>; openembedded-core@lists.openembedded.org > > > Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com> > > > Subject: RE: [OE-core] [PATCH] cve-check-map: Move 'upstream-wontfix' > > > to "Unpatched" status > > > > > > > > > > > > > -----Original Message----- > > > > From: Marko, Peter <Peter.Marko@siemens.com> > > > > Sent: Wednesday, July 24, 2024 12:04 PM > > > > To: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) > > > > <dnagodra@cisco.com>; openembedded-core@lists.openembedded.org > > > > Cc: xe-linux-external(mailer list) <xe-linux-external@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- > > > > core@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-external@cisco.com; Dhairya Nagodra <dnagodra@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. > > > > If you look at comments of entries using this category (7 in oe-core > > > scarthgap) > > > > these CVEs are more or less irrelevant. > > > > > > > > So this patch is from my point of view step in the wrong direction. > > > > If you really need to show these due to your CVE handling process, > > > > you can easily override this variable assignment in your own layer. > > > > > > > > > > > > > I tried this in my layer, created a .conf and included in my distro.conf file. > > > The issue is, it gets overwritten by cve-check-map.conf (as it is included > > later). > > > > If you create meta-<your-layer>/conf/cve-check-map.conf it will be included > > instead of the one from oe-core/poky. > > > > I tried this approach, it included both of the files, and my config was over written. > > # <path>/distro/openembedded-core/../my-layer/conf/distro/my-cve-check-map.conf > # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/defaultsetup.conf includes: > # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/default-providers.inc > # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/default-versions.inc > # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/default-distrovars.inc > # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/maintainers.inc > # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/tcmode-default.inc > # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/tclibc-glibc.inc > # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/uninative-flags.inc > # <path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/init-manager-none.inc > # <path>/distro/openembedded-core/../openembedded-core/meta/conf/documentation.conf > # <path>/distro/openembedded-core/../openembedded-core/meta/conf/licenses.conf > # <path>/distro/openembedded-core/../openembedded-core/meta/conf/sanity.conf > # <path>/distro/openembedded-core/../openembedded-core/meta/conf/cve-check-map.conf For that to work you need to use the same path. Above you have: conf/distro/my-cve-check-map.conf but it would have to match: conf/cve-check-map.conf Cheers, Richard
Hi Richard, JFYI, it seems that keeping the name same conf/cve-check-map.conf also doesn't work. Attached are logs at the bottom. Maybe due to the 'meta' dir? BTW, your new patch (bitbake.conf: Include cve-check-map earlier, before distro) should allow it to work. >-----Original Message----- >From: Richard Purdie <richard.purdie@linuxfoundation.org> >Sent: Monday, August 12, 2024 3:46 PM >To: Dhairya Nagodra -X (dnagodra - E INFOCHIPS LIMITED at Cisco) ><dnagodra@cisco.com>; Marko, Peter <Peter.Marko@siemens.com>; Marta >Rybczynska <rybczynska@gmail.com>; openembedded- >core@lists.openembedded.org >Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com> >Subject: Re: [OE-core] [PATCH] cve-check-map: Move 'upstream-wontfix' to >"Unpatched" status > >On Mon, 2024-08-12 at 10:08 +0000, Dhairya Nagodra -X (dnagodra - E >INFOCHIPS LIMITED at Cisco) wrote: >> >> >> > -----Original Message----- >> > From: Marko, Peter <Peter.Marko@siemens.com> >> > Sent: Wednesday, August 7, 2024 4:04 PM >> > To: Dhairya Nagodra -X (dnagodra - E INFOCHIPS LIMITED at Cisco) >> > <dnagodra@cisco.com>; Richard Purdie >> > <richard.purdie@linuxfoundation.org>; >> > Marta Rybczynska <rybczynska@gmail.com>; openembedded- >> > core@lists.openembedded.org >> > Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com> >> > Subject: RE: [OE-core] [PATCH] cve-check-map: Move >> > 'upstream-wontfix' to "Unpatched" status >> > >> > >> > >> > > -----Original Message----- >> > > From: Dhairya Nagodra -X (dnagodra - E INFOCHIPS LIMITED at Cisco) >> > > <dnagodra@cisco.com> >> > > Sent: Wednesday, August 7, 2024 12:17 >> > > To: Marko, Peter (ADV D EU SK BFS1) <Peter.Marko@siemens.com>; >> > > Richard Purdie <richard.purdie@linuxfoundation.org>; Marta >> > > Rybczynska <rybczynska@gmail.com>; >> > > openembedded-core@lists.openembedded.org >> > > Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com> >> > > Subject: RE: [OE-core] [PATCH] cve-check-map: Move 'upstream-wontfix' >> > > to "Unpatched" status >> > > >> > > >> > > >> > > > -----Original Message----- >> > > > From: Marko, Peter <Peter.Marko@siemens.com> >> > > > Sent: Wednesday, July 24, 2024 12:04 PM >> > > > To: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) >> > > > <dnagodra@cisco.com>; openembedded- >core@lists.openembedded.org >> > > > Cc: xe-linux-external(mailer list) <xe-linux-external@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- >> > > > core@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-external@cisco.com; Dhairya Nagodra >> > > > <dnagodra@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. >> > > > If you look at comments of entries using this category (7 in >> > > > oe-core >> > > scarthgap) >> > > > these CVEs are more or less irrelevant. >> > > > >> > > > So this patch is from my point of view step in the wrong direction. >> > > > If you really need to show these due to your CVE handling >> > > > process, you can easily override this variable assignment in your own >layer. >> > > > >> > > >> > > >> > > I tried this in my layer, created a .conf and included in my distro.conf file. >> > > The issue is, it gets overwritten by cve-check-map.conf (as it is >> > > included >> > later). >> > >> > If you create meta-<your-layer>/conf/cve-check-map.conf it will be >> > included instead of the one from oe-core/poky. >> > >> >> I tried this approach, it included both of the files, and my config was over >written. >> >> # >> <path>/distro/openembedded-core/../my-layer/conf/distro/my-cve-check- >m >> ap.conf # >> <path>/distro/openembedded-core/../openembedded- >core/meta/conf/distro/defaultsetup.conf includes: >> # >> <path>/distro/openembedded-core/../openembedded- >core/meta/conf/distro/ >> include/default-providers.inc # >> <path>/distro/openembedded-core/../openembedded- >core/meta/conf/distro/ >> include/default-versions.inc # >> <path>/distro/openembedded-core/../openembedded- >core/meta/conf/distro/ >> include/default-distrovars.inc # >> <path>/distro/openembedded-core/../openembedded- >core/meta/conf/distro/ >> include/maintainers.inc # >> <path>/distro/openembedded-core/../openembedded- >core/meta/conf/distro/ >> include/tcmode-default.inc # >> <path>/distro/openembedded-core/../openembedded- >core/meta/conf/distro/ >> include/tclibc-glibc.inc # >> <path>/distro/openembedded-core/../openembedded- >core/meta/conf/distro/ >> include/uninative-flags.inc # >> <path>/distro/openembedded-core/../openembedded- >core/meta/conf/distro/ >> include/init-manager-none.inc # >> <path>/distro/openembedded-core/../openembedded- >core/meta/conf/documen >> tation.conf # >> <path>/distro/openembedded-core/../openembedded- >core/meta/conf/license >> s.conf # >> <path>/distro/openembedded-core/../openembedded- >core/meta/conf/sanity. >> conf # >> <path>/distro/openembedded-core/../openembedded-core/meta/conf/cve- >che >> ck-map.conf > > >For that to work you need to use the same path. Above you have: > >conf/distro/my-cve-check-map.conf > >but it would have to match: > >conf/cve-check-map.conf > # /<path>/distro/openembedded-core/../meta-mylayer/conf/cve-check-map.conf # /<path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/defaultsetup.conf includes: # /<path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/default-providers.inc # /<path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/default-versions.inc # /<path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/default-distrovars.inc # /<path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/maintainers.inc # /<path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/tcmode-default.inc # /<path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/tclibc-glibc.inc # /<path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/uninative-flags.inc # /<path>/distro/openembedded-core/../openembedded-core/meta/conf/distro/include/init-manager-none.inc # /<path>/distro/openembedded-core/../openembedded-core/meta/conf/documentation.conf # /<path>/distro/openembedded-core/../openembedded-core/meta/conf/licenses.conf # /<path>/distro/openembedded-core/../openembedded-core/meta/conf/sanity.conf # /<path>/distro/openembedded-core/../openembedded-core/meta/conf/cve-check-map.conf Regards, Dhairya >Cheers, > >Richard > >
diff --git a/meta/conf/cve-check-map.conf b/meta/conf/cve-check-map.conf index b9df41a6f3..7ff53f5601 100644 --- a/meta/conf/cve-check-map.conf +++ b/meta/conf/cve-check-map.conf @@ -15,6 +15,8 @@ CVE_CHECK_STATUSMAP[unpatched] = "Unpatched" CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched" # use when CVE fix is not compatible to the current version and cannot be backported. CVE_CHECK_STATUSMAP[cannot-backport] = "Unpatched" +# use when upstream acknowledged the vulnerability but does not plan to fix it +CVE_CHECK_STATUSMAP[upstream-wontfix] = "Unpatched" # used for migration from old concept, do not use for new vulnerabilities CVE_CHECK_STATUSMAP[ignored] = "Ignored" @@ -26,5 +28,3 @@ CVE_CHECK_STATUSMAP[disputed] = "Ignored" CVE_CHECK_STATUSMAP[not-applicable-config] = "Ignored" # use when vulnerability affects other platform (e.g. Windows or Debian) CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored" -# use when upstream acknowledged the vulnerability but does not plan to fix it -CVE_CHECK_STATUSMAP[upstream-wontfix] = "Ignored"
- 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. Signed-off-by: Dhairya Nagodra <dnagodra@cisco.com> --- meta/conf/cve-check-map.conf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)