diff mbox series

[v4,1/3] cve-check: add option to add additional patched CVEs

Message ID 20230519081850.82586-1-andrej.valek@siemens.com
State New
Headers show
Series [v4,1/3] cve-check: add option to add additional patched CVEs | expand

Commit Message

Andrej Valek May 19, 2023, 8:18 a.m. UTC 
- Replace CVE_CHECK_IGNORE with CVE_STATUS + [CVE_STATUS_REASONING] to be
more flexible. CVE_STATUS should contain flag for each CVE with accepted
values "Ignored", "Not applicable" or "Patched". It allows to add
a status for each CVEs.
- Optional CVE_STATUS_REASONING flag variable may contain a reason
why the CVE status was used. It will be added in csv/json report like
a new "reason" entry.
- Settings the same status and reason for multiple CVEs is possible
via CVE_STATUS_GROUPS variable.
- All listed CVEs in CVE_CHECK_IGNORE are copied to CVE_STATUS with
value "Ignored" like a fallback.

Examples of usage:
CVE_STATUS[CVE-1234-0001] = "Ignored" # or "Not applicable" or "Patched"
CVE_STATUS[CVE-1234-0002] = "Not applicable"
CVE_STATUS_REASONING[CVE-1234-0002] = "Issue only applies on Windows"

CVE_STATUS_GROUPS = "CVE_STATUS_WIN CVE_STATUS_PATCHED"
CVE_STATUS_WIN = "CVE-1234-0001 CVE-1234-0002"
CVE_STATUS_WIN[status] = "Not applicable"
CVE_STATUS_WIN[reason] = "Issue only applies on Windows"

CVE_STATUS_PATCHED = "CVE-1234-0003 CVE-1234-0004"
CVE_STATUS_PATCHED[status] = "Patched"
CVE_STATUS_PATCHED[reason] = "Fixed externally"

Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 meta/classes/cve-check.bbclass | 44 ++++++++++++++++++++++++++++++----
 meta/lib/oe/cve_check.py       |  6 +++++
 2 files changed, 45 insertions(+), 5 deletions(-)

Comments

Michael Opdenacker May 19, 2023, 1:09 p.m. UTC | #1 
Hi Andrej,

On 19.05.23 at 10:18, Andrej Valek via lists.openembedded.org wrote:
> - Replace CVE_CHECK_IGNORE with CVE_STATUS + [CVE_STATUS_REASONING] to be
> more flexible. CVE_STATUS should contain flag for each CVE with accepted
> values "Ignored", "Not applicable" or "Patched". It allows to add
> a status for each CVEs.
> - Optional CVE_STATUS_REASONING flag variable may contain a reason
> why the CVE status was used. It will be added in csv/json report like
> a new "reason" entry.


I'm not a native English speaker, but what about just 
"CVE_STATUS_REASON" instead of "CVE_STATUS_REASONING"?

"Reasoning" is a mental process if I understand correctly. See 
https://www.englishforums.com/English/ReasonVsReasoning/zdgdw/post.htm. 
It seems to me that the term "reason" should be sufficient, as the 
"reason" flag that you're using.

I'd be interested in what others think about this...
Thanks in advance
Cheers

Michael.
Andrej Valek May 19, 2023, 1:19 p.m. UTC | #2 
Hello Michael,

I wanted to use a "CVE_STATUS_REASON", but it was advised here
https://lists.openembedded.org/g/openembedded-core/message/181037 by Richard. So
I was thinking, that it has to correct.

Regards,
Andrej

On Fri, 2023-05-19 at 15:09 +0200, Michael Opdenacker wrote:
> Hi Andrej,
> 
> On 19.05.23 at 10:18, Andrej Valek via lists.openembedded.org wrote:
> > - Replace CVE_CHECK_IGNORE with CVE_STATUS + [CVE_STATUS_REASONING] to be
> > more flexible. CVE_STATUS should contain flag for each CVE with accepted
> > values "Ignored", "Not applicable" or "Patched". It allows to add
> > a status for each CVEs.
> > - Optional CVE_STATUS_REASONING flag variable may contain a reason
> > why the CVE status was used. It will be added in csv/json report like
> > a new "reason" entry.
> 
> 
> I'm not a native English speaker, but what about just 
> "CVE_STATUS_REASON" instead of "CVE_STATUS_REASONING"?
> 
> "Reasoning" is a mental process if I understand correctly. See 
> https://www.englishforums.com/English/ReasonVsReasoning/zdgdw/post.htm. 
> It seems to me that the term "reason" should be sufficient, as the 
> "reason" flag that you're using.
> 
> I'd be interested in what others think about this...
> Thanks in advance
> Cheers
> 
> Michael.
>
Sanjaykumar kantibhai Chitroda -X (schitrod - E-INFO CHIPS INC at Cisco) May 23, 2023, 11:39 a.m. UTC | #3 
Hello Richard and Andrej,

Recently, I have observed the OpenEmbedded team is going beyond "patched" status for CVE. This change is required and helps to capture additional status.
We can identify and define the reason for a whitelisted or CVE that are not "patched".

Customers can get this reason and identify whether their product is vulnerable or not with a specific vulnerability.

VEX is the standard tool used by many customers to check the vulnerability of the product.
I suggest we adopt the VEX standard instead of "Ignored" or "Not applicable".
○ NOT AFFECTED – No remediation is required regarding this vulnerability. 
○ AFFECTED – Actions are recommended to remediate or address this vulnerability. 
○ FIXED – These product versions contain a fix for the vulnerability. 
○ UNDER INVESTIGATION – It is not yet known whether these product versions are affected by the vulnerability. An update will be provided in a later release.

The main four categories of VEX standard cover all possible cases, which are required to consider all potential cases.
We can expand the cve-check to validate main VEX standard and we can use sub-status information as a possible reason for reference.

Please find below reference information on how VEX and SBOM can work together:
https://www.rezilion.com/guides/vulnerability-exploitability-exchange-vex-a-guide/

More information on VEX standards and use cases:
https://www.cisa.gov/sites/default/files/publications/VEX_Use_Cases_Aprill2022.pdf

Thanks,
Sanjay

-----Original Message-----
From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Andrej Valek via lists.openembedded.org
Sent: Friday, May 19, 2023 6:49 PM
To: openembedded-core@lists.openembedded.org; michael.opdenacker@bootlin.com
Cc: Marko, Peter <Peter.Marko@siemens.com>
Subject: Re: [OE-core][PATCH v4 1/3] cve-check: add option to add additional patched CVEs

Hello Michael,

I wanted to use a "CVE_STATUS_REASON", but it was advised here
https://lists.openembedded.org/g/openembedded-core/message/181037 by Richard. So I was thinking, that it has to correct.

Regards,
Andrej

On Fri, 2023-05-19 at 15:09 +0200, Michael Opdenacker wrote:
> Hi Andrej,
> 
> On 19.05.23 at 10:18, Andrej Valek via lists.openembedded.org wrote:
> > - Replace CVE_CHECK_IGNORE with CVE_STATUS + [CVE_STATUS_REASONING] 
> > to be more flexible. CVE_STATUS should contain flag for each CVE 
> > with accepted values "Ignored", "Not applicable" or "Patched". It 
> > allows to add a status for each CVEs.
> > - Optional CVE_STATUS_REASONING flag variable may contain a reason 
> > why the CVE status was used. It will be added in csv/json report 
> > like a new "reason" entry.
> 
> 
> I'm not a native English speaker, but what about just 
> "CVE_STATUS_REASON" instead of "CVE_STATUS_REASONING"?
> 
> "Reasoning" is a mental process if I understand correctly. See 
> https://www.englishforums.com/English/ReasonVsReasoning/zdgdw/post.htm.
> It seems to me that the term "reason" should be sufficient, as the 
> "reason" flag that you're using.
> 
> I'd be interested in what others think about this...
> Thanks in advance
> Cheers
> 
> Michael.
>
Luca Ceresoli June 22, 2023, 12:42 p.m. UTC | #4 
Hello Andrej,

On Thu, 22 Jun 2023 08:59:02 +0200
"Andrej Valek via lists.openembedded.org"
<andrej.valek=siemens.com@lists.openembedded.org> wrote:

> After discussion in all parallel threads we proposed following variant which
> covers both expressed requirements to have very small number of different cve
> statuses and also very large number of them at the same time.
> This is a compromise version which maybe is not ideal but deals with
> conflicting responses we got.
> 
> Changes compare to version 6:
>  - added conversion from CVE_CHECK_IGNORE to CVE_STATUS
>  - added comments for all statuses
>  - dropped "not-affected" status
>   - conversion showed that it is not very usefull
>  - added "disputed" status
> 
> Documentation will be updated in separated repository.

This patchset generates a lot of warnings when run on the autobuilders.
Here are a few:

WARNING: qemu-8.0.0-r0 do_create_spdx: Invalid detail cpe-incorrect for CVE_STATUS[CVE-2017-5957] = "cpe-incorrect: Applies against virglrender < 0.6.0 and not qemu itself", fallback to Unpatched
WARNING: qemu-8.0.0-r0 do_create_spdx: Invalid detail not-applicable-config for CVE_STATUS[CVE-2007-0998] = "not-applicable-config: The VNC server can expose host files uder some circumstances. We don't enable it by default.", fallback to Unpatched
WARNING: qemu-8.0.0-r0 do_create_spdx: Invalid detail disputed for CVE_STATUS[CVE-2018-18438] = "disputed: The issues identified by this CVE were determined to not constitute a vulnerability.", fallback to Unpatched
NOTE: recipe python3-calver-2022.6.26-r0: task do_create_runtime_spdx: Succeeded
WARNING: qemu-8.0.0-r0 do_create_spdx: Invalid detail not-applicable-platform for CVE_STATUS[CVE-2023-0664] = "not-applicable-platform: Issue only applies on Windows", fallback to Unpatched

WARNING: cpio-2.14-r0 do_create_spdx: Invalid detail not-applicable-platform for CVE_STATUS[CVE-2010-4226] = "not-applicable-platform: Issue applies to use of cpio in SUSE/OBS", fallback to Unpatched

WARNING: bluez5-5.66-r0 do_create_spdx: Invalid detail cpe-incorrect for CVE_STATUS[CVE-2022-3563] = "cpe-incorrect: This issues have kernel fixes rather than bluez fixes", fallback to Unpatched
WARNING: bluez5-5.66-r0 do_create_spdx: Invalid detail cpe-incorrect for CVE_STATUS[CVE-2022-3637] = "cpe-incorrect: This issues have kernel fixes rather than bluez fixes", fallback to Unpatched

For a more complete list you can look at the build page:
https://swatbot.yoctoproject.org/collection/17294/

All/most of the warnings are about CVEs.

I haven't looked in detail at what is the intended behavior of your
patch set, however I'm removing it from my testing branch for the time
being.

Best regards,
Luca
Andrej Valek June 22, 2023, 1:50 p.m. UTC | #5 
Hello Luca,

How can I reproduce it? I've executed "bitbake qemu -c create_spdx" but it
didn't print any warning. Should I build an image?

Regards,
Andrej

On Thu, 2023-06-22 at 14:42 +0200, Luca Ceresoli wrote:
> Hello Andrej,
> 
> On Thu, 22 Jun 2023 08:59:02 +0200
> "Andrej Valek via lists.openembedded.org"
> <andrej.valek=siemens.com@lists.openembedded.org> wrote:
> 
> > After discussion in all parallel threads we proposed following variant which
> > covers both expressed requirements to have very small number of different
> > cve
> > statuses and also very large number of them at the same time.
> > This is a compromise version which maybe is not ideal but deals with
> > conflicting responses we got.
> > 
> > Changes compare to version 6:
> >  - added conversion from CVE_CHECK_IGNORE to CVE_STATUS
> >  - added comments for all statuses
> >  - dropped "not-affected" status
> >   - conversion showed that it is not very usefull
> >  - added "disputed" status
> > 
> > Documentation will be updated in separated repository.
> 
> This patchset generates a lot of warnings when run on the autobuilders.
> Here are a few:
> 
> WARNING: qemu-8.0.0-r0 do_create_spdx: Invalid detail cpe-incorrect for
> CVE_STATUS[CVE-2017-5957] = "cpe-incorrect: Applies against virglrender <
> 0.6.0 and not qemu itself", fallback to Unpatched
> WARNING: qemu-8.0.0-r0 do_create_spdx: Invalid detail not-applicable-config
> for CVE_STATUS[CVE-2007-0998] = "not-applicable-config: The VNC server can
> expose host files uder some circumstances. We don't enable it by default.",
> fallback to Unpatched
> WARNING: qemu-8.0.0-r0 do_create_spdx: Invalid detail disputed for
> CVE_STATUS[CVE-2018-18438] = "disputed: The issues identified by this CVE were
> determined to not constitute a vulnerability.", fallback to Unpatched
> NOTE: recipe python3-calver-2022.6.26-r0: task do_create_runtime_spdx:
> Succeeded
> WARNING: qemu-8.0.0-r0 do_create_spdx: Invalid detail not-applicable-platform
> for CVE_STATUS[CVE-2023-0664] = "not-applicable-platform: Issue only applies
> on Windows", fallback to Unpatched
> 
> WARNING: cpio-2.14-r0 do_create_spdx: Invalid detail not-applicable-platform
> for CVE_STATUS[CVE-2010-4226] = "not-applicable-platform: Issue applies to use
> of cpio in SUSE/OBS", fallback to Unpatched
> 
> WARNING: bluez5-5.66-r0 do_create_spdx: Invalid detail cpe-incorrect for
> CVE_STATUS[CVE-2022-3563] = "cpe-incorrect: This issues have kernel fixes
> rather than bluez fixes", fallback to Unpatched
> WARNING: bluez5-5.66-r0 do_create_spdx: Invalid detail cpe-incorrect for
> CVE_STATUS[CVE-2022-3637] = "cpe-incorrect: This issues have kernel fixes
> rather than bluez fixes", fallback to Unpatched
> 
> For a more complete list you can look at the build page:
> https://swatbot.yoctoproject.org/collection/17294/
> 
> All/most of the warnings are about CVEs.
> 
> I haven't looked in detail at what is the intended behavior of your
> patch set, however I'm removing it from my testing branch for the time
> being.
> 
> Best regards,
> Luca
>
Luca Ceresoli June 22, 2023, 1:55 p.m. UTC | #6 
Hello Andrej,

On Thu, 22 Jun 2023 13:50:32 +0000
"Andrej Valek via lists.openembedded.org"
<andrej.valek=siemens.com@lists.openembedded.org> wrote:

> Hello Luca,
> 
> How can I reproduce it? I've executed "bitbake qemu -c create_spdx" but it
> didn't print any warning. Should I build an image?

I don't know how to reproduce _exactly_ the build environment of the
autobuilders, however the logs have some good hints (click the "stdio"
links in the page at the URL I provided). E.g. for the qemuarm64
builder it says:

Running '. ./oe-init-build-env; bitbake core-image-sato core-image-sato-sdk core-image-minimal core-image-minimal-dev core-image-sato:do_populate_sdk -k' ...
MACHINE = "qemuarm64"
DISTRO = "poky"
...and more settings you might want to put in your local.conf...

So you may try that.

Luca
Andrej Valek June 22, 2023, 1:59 p.m. UTC | #7 
Hello Luca,

I wanted to check the logs, but it requires a login/password. Would it be
possible to send a link where is not required? Maybe here
https://autobuilder.yoctoproject.org/typhoon/#/ ?

Regards,
Andrej

On Thu, 2023-06-22 at 15:55 +0200, Luca Ceresoli wrote:
> Hello Andrej,
> 
> On Thu, 22 Jun 2023 13:50:32 +0000
> "Andrej Valek via lists.openembedded.org"
> <andrej.valek=siemens.com@lists.openembedded.org> wrote:
> 
> > Hello Luca,
> > 
> > How can I reproduce it? I've executed "bitbake qemu -c create_spdx" but it
> > didn't print any warning. Should I build an image?
> 
> I don't know how to reproduce _exactly_ the build environment of the
> autobuilders, however the logs have some good hints (click the "stdio"
> links in the page at the URL I provided). E.g. for the qemuarm64
> builder it says:
> 
> Running '. ./oe-init-build-env; bitbake core-image-sato core-image-sato-sdk
> core-image-minimal core-image-minimal-dev core-image-sato:do_populate_sdk -k'
> ...
> MACHINE = "qemuarm64"
> DISTRO = "poky"
> ...and more settings you might want to put in your local.conf...
> 
> So you may try that.
> 
> Luca
>
Andrej Valek June 22, 2023, 2:07 p.m. UTC | #8 
OK,

Now I know what's the problem. SPDX are being created without inheriting the
cve-check class.

Regards,
Andrej

On Thu, 2023-06-22 at 15:59 +0200, Valek Andrej wrote:
> Hello Luca,
> 
> I wanted to check the logs, but it requires a login/password. Would it be
> possible to send a link where is not required? Maybe here
> https://autobuilder.yoctoproject.org/typhoon/#/ ?
> 
> Regards,
> Andrej
> 
> On Thu, 2023-06-22 at 15:55 +0200, Luca Ceresoli wrote:
> > Hello Andrej,
> > 
> > On Thu, 22 Jun 2023 13:50:32 +0000
> > "Andrej Valek via lists.openembedded.org"
> > <andrej.valek=siemens.com@lists.openembedded.org> wrote:
> > 
> > > Hello Luca,
> > > 
> > > How can I reproduce it? I've executed "bitbake qemu -c create_spdx" but it
> > > didn't print any warning. Should I build an image?
> > 
> > I don't know how to reproduce _exactly_ the build environment of the
> > autobuilders, however the logs have some good hints (click the "stdio"
> > links in the page at the URL I provided). E.g. for the qemuarm64
> > builder it says:
> > 
> > Running '. ./oe-init-build-env; bitbake core-image-sato core-image-sato-sdk
> > core-image-minimal core-image-minimal-dev core-image-sato:do_populate_sdk -
> > k'
> > ...
> > MACHINE = "qemuarm64"
> > DISTRO = "poky"
> > ...and more settings you might want to put in your local.conf...
> > 
> > So you may try that.
> > 
> > Luca
> > 
>
Luca Ceresoli June 22, 2023, 4:24 p.m. UTC | #9 
Hello Andrej,

On Thu, 22 Jun 2023 14:07:41 +0000
"Andrej Valek via lists.openembedded.org"
<andrej.valek=siemens.com@lists.openembedded.org> wrote:

> OK,
> 
> Now I know what's the problem. SPDX are being created without inheriting the
> cve-check class.
> 
> Regards,
> Andrej
> 
> On Thu, 2023-06-22 at 15:59 +0200, Valek Andrej wrote:
> > Hello Luca,
> > 
> > I wanted to check the logs, but it requires a login/password. Would it be
> > possible to send a link where is not required? Maybe here
> > https://autobuilder.yoctoproject.org/typhoon/#/ ?

Ouch, sorry about that! Apparently you already found the root cause,
however here is the a-full build public link, in case it were still
useful:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/5505

Luca
Andrej Valek July 19, 2023, 10:26 a.m. UTC | #10 
Hello,

I would like to ask, what's the status here?

Regards,
Andrej

On Fri, 2023-06-23 at 13:14 +0200, Andrej Valek wrote:
> After discussion in all parallel threads we proposed following variant which
> covers both expressed requirements to have very small number of different cve
> statuses and also very large number of them at the same time.
> This is a compromise version which maybe is not ideal but deals with
> conflicting responses we got.
> 
> Changes compared to version 8:
>  - moved CVE_CHECK_STATUSMAP into separated cve-check-map.conf file
>   - this will allow to use it without inheriting the cve-check class, like for
> SPDX
> 
> Documentation will be updated in separated repository.
> 
>  meta/classes/cve-check.bbclass                |  81 +++-
>  meta/conf/bitbake.conf                        |   1 +
>  meta/conf/cve-check-map.conf                  |  28 ++
>  .../distro/include/cve-extra-exclusions.inc   | 371 +++++++++---------
>  meta/lib/oe/cve_check.py                      |  25 ++
>  meta/lib/oeqa/selftest/cases/cve_check.py     |  26 +-
>  meta/recipes-bsp/grub/grub2.inc               |   6 +-
>  meta/recipes-connectivity/avahi/avahi_0.8.bb  |   3 +-
>  .../recipes-connectivity/bind/bind_9.18.15.bb |   2 +-
>  .../bluez5/bluez5_5.66.bb                     |   4 +-
>  .../openssh/openssh_9.3p1.bb                  |   9 +-
>  .../openssl/openssl_3.1.1.bb                  |   3 +-
>  meta/recipes-core/coreutils/coreutils_9.3.bb  |   4 +-
>  meta/recipes-core/glibc/glibc_2.37.bb         |  17 +-
>  meta/recipes-core/libxml/libxml2_2.10.4.bb    |   4 -
>  meta/recipes-core/systemd/systemd_253.3.bb    |   3 -
>  meta/recipes-devtools/cmake/cmake.inc         |   4 +-
>  meta/recipes-devtools/flex/flex_2.6.4.bb      |   6 +-
>  meta/recipes-devtools/gcc/gcc-13.1.inc        |   3 +-
>  meta/recipes-devtools/git/git_2.39.3.bb       |   7 -
>  meta/recipes-devtools/jquery/jquery_3.6.3.bb  |   5 +-
>  meta/recipes-devtools/ninja/ninja_1.11.1.bb   |   3 +-
>  .../recipes-devtools/python/python3_3.11.3.bb |  13 +-
>  meta/recipes-devtools/qemu/qemu.inc           |  13 +-
>  meta/recipes-devtools/rsync/rsync_3.2.7.bb    |   3 -
>  meta/recipes-devtools/tcltk/tcl_8.6.13.bb     |   4 -
>  meta/recipes-extended/cpio/cpio_2.14.bb       |   3 +-
>  meta/recipes-extended/cups/cups.inc           |  17 +-
>  .../ghostscript/ghostscript_10.01.1.bb        |   3 +-
>  .../iputils/iputils_20221126.bb               |   5 +-
>  .../libtirpc/libtirpc_1.3.3.bb                |   3 +-
>  .../logrotate/logrotate_3.21.0.bb             |   5 +-
>  meta/recipes-extended/procps/procps_4.0.3.bb  |   4 -
>  meta/recipes-extended/shadow/shadow_4.13.bb   |   7 +-
>  meta/recipes-extended/unzip/unzip_6.0.bb      |   3 +-
>  .../xinetd/xinetd_2.3.15.4.bb                 |   2 +-
>  meta/recipes-extended/zip/zip_3.0.bb          |   7 +-
>  .../libnotify/libnotify_0.8.2.bb              |   2 +-
>  meta/recipes-gnome/librsvg/librsvg_2.56.0.bb  |   3 +-
>  meta/recipes-graphics/builder/builder_0.1.bb  |   3 +-
>  .../xorg-xserver/xserver-xorg.inc             |  19 +-
>  .../linux/cve-exclusion_6.1.inc               |  11 +-
>  .../libpng/libpng_1.6.39.bb                   |   3 +-
>  meta/recipes-multimedia/libtiff/tiff_4.5.0.bb |  10 +-
>  .../libgcrypt/libgcrypt_1.10.2.bb             |   4 +-
>  .../recipes-support/libxslt/libxslt_1.1.38.bb |   4 +-
>  meta/recipes-support/lz4/lz4_1.9.4.bb         |   3 +-
>  meta/recipes-support/sqlite/sqlite3_3.41.2.bb |   7 -
>  48 files changed, 403 insertions(+), 373 deletions(-)
>  create mode 100644 meta/conf/cve-check-map.conf
>
Richard Purdie July 19, 2023, 10:54 a.m. UTC | #11 
On Wed, 2023-07-19 at 10:26 +0000, Valek, Andrej wrote:
> Hello,
> 
> I would like to ask, what's the status here?

I've asked for some people to help review it and I'm waiting on their
feedback. FWIW they did promise "this morning" yesterday so they have
around 6 minutes!

Cheers,

Richard
Ross Burton July 19, 2023, 11:16 a.m. UTC | #12 
On 19 Jul 2023, at 11:54, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Wed, 2023-07-19 at 10:26 +0000, Valek, Andrej wrote:
>> Hello,
>> 
>> I would like to ask, what's the status here?
> 
> I've asked for some people to help review it and I'm waiting on their
> feedback. FWIW they did promise "this morning" yesterday so they have
> around 6 minutes!

I suspect I was that person :). I have no major objections to the patch now.

Cheers,
Ross
Andrej Valek July 19, 2023, 12:03 p.m. UTC | #13 
Even better,

So I will make one more rebase, just for "[OE-core][PATCH v9 3/3] cve_check:
convert CVE_CHECK_IGNORE to CVE_STATUS"

Regards,
Andrej

On Wed, 2023-07-19 at 11:16 +0000, Ross Burton wrote:
> On 19 Jul 2023, at 11:54, Richard Purdie <richard.purdie@linuxfoundation.org>
> wrote:
> > 
> > On Wed, 2023-07-19 at 10:26 +0000, Valek, Andrej wrote:
> > > Hello,
> > > 
> > > I would like to ask, what's the status here?
> > 
> > I've asked for some people to help review it and I'm waiting on their
> > feedback. FWIW they did promise "this morning" yesterday so they have
> > around 6 minutes!
> 
> I suspect I was that person :). I have no major objections to the patch now.
> 
> Cheers,
> Ross
Marta Rybczynska July 20, 2023, 4:41 p.m. UTC | #14 
On Wed, Jul 19, 2023 at 2:03 PM Andrej Valek via lists.openembedded.org
<andrej.valek=siemens.com@lists.openembedded.org> wrote:

> Even better,
>
> So I will make one more rebase, just for "[OE-core][PATCH v9 3/3]
> cve_check:
> convert CVE_CHECK_IGNORE to CVE_STATUS"
>
>
This version looks best from all I've seen. Let's get it in in this
version. I'll have a pachset to fix a few issues after we get multiple
fetchers in. I *think* I will be able to use it with multi-fetchers.

Kind regards,
Marta
diff mbox series

Patch

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index bd9e7e7445c..44462de7445 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -70,12 +70,15 @@  CVE_CHECK_COVERAGE ??= "1"
 # Skip CVE Check for packages (PN)
 CVE_CHECK_SKIP_RECIPE ?= ""
 
-# Ingore the check for a given list of CVEs. If a CVE is found,
-# then it is considered patched. The value is a string containing
-# space separated CVE values:
+# Replace NVD DB check status for a given CVE. Each of CVE has to be mentioned
+# separately with optional reason for this status.
 #
-# CVE_CHECK_IGNORE = 'CVE-2014-2524 CVE-2018-1234'
+# CVE_STATUS[CVE-1234-0001] = "Ignored" # or "Not applicable" or "Patched"
+# CVE_STATUS[CVE-1234-0002] = "Not applicable"
+# CVE_STATUS_REASONING[CVE-1234-0002] = "Issue only applies on Windows"
 #
+# CVE_CHECK_IGNORE is deprecated and CVE_STATUS has to be used instead.
+# Keep CVE_CHECK_IGNORE until other layers migrate to new variables
 CVE_CHECK_IGNORE ?= ""
 
 # Layers to be excluded
@@ -88,6 +91,25 @@  CVE_CHECK_LAYER_INCLUDELIST ??= ""
 # set to "alphabetical" for version using single alphabetical character as increment release
 CVE_VERSION_SUFFIX ??= ""
 
+python () {
+    # Fallback all CVEs from CVE_CHECK_IGNORE to CVE_STATUS
+    cve_check_ignore = d.getVar("CVE_CHECK_IGNORE")
+    if cve_check_ignore:
+        bb.warn("CVE_CHECK_IGNORE has been deprecated, use CVE_STATUS instead")
+        set_cves_statuses(d, d.getVar("CVE_CHECK_IGNORE"), "Ignored")
+
+    # Process CVE_STATUS_GROUPS to set multiple statuses and optional reasons at once
+    for cve_status_group in (d.getVar("CVE_STATUS_GROUPS") or "").split():
+        set_cves_statuses(d, d.getVar(cve_status_group) or "",
+                          d.getVarFlag(cve_status_group, "status"),
+                          d.getVarFlag(cve_status_group, "reason"))
+}
+
+def set_cves_statuses(d, cves, status, reason=""):
+    for cve in cves.split():
+        d.setVarFlag("CVE_STATUS", cve, status)
+        d.setVarFlag("CVE_STATUS_REASONING", cve, reason)
+
 def generate_json_report(d, out_path, link_path):
     if os.path.exists(d.getVar("CVE_CHECK_SUMMARY_INDEX_PATH")):
         import json
@@ -282,7 +304,13 @@  def check_cves(d, patched_cves):
         bb.note("Recipe has been skipped by cve-check")
         return ([], [], [], [])
 
-    cve_ignore = d.getVar("CVE_CHECK_IGNORE").split()
+    # Convert CVE_STATUS into ignored CVEs and check validity
+    cve_ignore = []
+    for cve, status in (d.getVarFlags("CVE_STATUS") or {}).items():
+        if status in ["Not applicable", "Ignored"]:
+            cve_ignore.append(cve)
+        elif status not in ["Patched"]:
+            bb.error("Unsupported status %s in CVE_STATUS[%s]" % (status, cve))
 
     import sqlite3
     db_file = d.expand("file:${CVE_CHECK_DB_FILE}?mode=ro")
@@ -455,6 +483,9 @@  def cve_write_data_text(d, patched, unpatched, ignored, cve_data):
         else:
             unpatched_cves.append(cve)
             write_string += "CVE STATUS: Unpatched\n"
+        reasoning = d.getVarFlag("CVE_STATUS_REASONING", cve)
+        if reasoning:
+            write_string += "CVE REASON: %s\n" % reasoning
         write_string += "CVE SUMMARY: %s\n" % cve_data[cve]["summary"]
         write_string += "CVSS v2 BASE SCORE: %s\n" % cve_data[cve]["scorev2"]
         write_string += "CVSS v3 BASE SCORE: %s\n" % cve_data[cve]["scorev3"]
@@ -576,6 +607,9 @@  def cve_write_data_json(d, patched, unpatched, ignored, cve_data, cve_status):
             "status" : status,
             "link": issue_link
         }
+        reasoning = d.getVarFlag("CVE_STATUS_REASONING", cve)
+        if reasoning:
+            cve_item["reason"] = reasoning
         cve_list.append(cve_item)
 
     package_data["issue"] = cve_list
diff --git a/meta/lib/oe/cve_check.py b/meta/lib/oe/cve_check.py
index dbaa0b373a3..f47dd9920ef 100644
--- a/meta/lib/oe/cve_check.py
+++ b/meta/lib/oe/cve_check.py
@@ -130,6 +130,12 @@  def get_patched_cves(d):
         if not fname_match and not text_match:
             bb.debug(2, "Patch %s doesn't solve CVEs" % patch_file)
 
+    # Search for additional patched CVEs
+    for cve, status in (d.getVarFlags("CVE_STATUS") or {}).items():
+        if status == "Patched":
+            bb.debug(2, "CVE %s is additionally patched" % cve)
+            patched_cves.add(cve)
+
     return patched_cves