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 |
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.
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. >
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. >
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
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 >
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
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 >
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 > > >
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
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 >
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
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
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
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 --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