Move to the FKIE feed by default, as it is showing better stability
than NVD2. Content of the feed should be the same.
(From OE-Core rev: 10580a6d36aa1366732f9c030345bd4590eb9f74)
Signed-off-by: Marta Rybczynska <marta.rybczynska@ygreky.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
According to Yocto reference manual, in description of the
IMAGE_LINK_NAME variable, it is said that
It is possible to set this to "" to disable symlink creation,
however, you also need to set :term:`IMAGE_NAME` to still have
a reasonable value e.g.::
IMAGE_LINK_NAME = ""
IMAGE_NAME = "${IMAGE_BASENAME}${IMAGE_MACHINE_SUFFIX}${IMAGE_VERSION_SUFFIX}"
However, when using following additions in local.conf file:
INHERIT += "cve-check"
IMAGE_LINK_NAME = ""
IMAGE_NAME = "${IMAGE_BASENAME}${IMAGE_MACHINE_SUFFIX}${IMAGE_VERSION_SUFFIX}"
the implicit symlink creation in cve_check_write_rootfs_manifest leads
to following build failure
$ bitbake core-image-minimal core-image-base
...
ERROR: core-image-base-1.0-r0 do_image_complete: Recipe core-image-base is trying to install files into a shared area when those files already exist. The files and the manifests listing them are:
/home/poky/build/tmp/deploy/images/qemux86-64/.json
(matched in manifest-qemux86_64-core-image-minimal.image_complete)
Please adjust the recipes so only one recipe provides a given file.
Mitigate the issue by creating the symlink only in case IMAGE_LINK_NAME
has not been set to empty string.
(From OE-Core rev: 64bfec359bd909761ce0a6a716286d938ed162d1)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow choice of one of three feeds and update task dependencies
accordingly. All feeds contain data from NVD and are stored in
different files.
Set the NVD_DB_VERSION variable to choose feed:
NVD2 (default) - the NVD feed with API version 2
NVD1 - the NVD JSON feed (deprecated)
FKIE - the FKIE-CAD feed reconstruction
In case of malformed database feed name, we default to NVD2 and show
an error.
(From OE-Core rev: f265812bfb6797aee10e7be42865736c9ff3478f)
Signed-off-by: Marta Rybczynska <marta.rybczynska@ygreky.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently flag cvesInRecord is set to false if all CVEs are ignored or
patched. This is inconsistent as it shows false if a CVE was fixed via
patch and true if this CVE was fixed by upgrade. In both cases the CVE
is valid and was fixed.
As I understand this flag, it should say if any CVE exists for
particular component's product (regardless of how this CVE is handled)
and can be used to validate if a product is correctly set.
Note that skipping ignored CVEs may make sense in some cases, as ignored
may mean that NVD DB is wrong, but in many cases it is ignored for other
reasons. Further patch can be done to evaluate ignore subtype but that
would be against my understanding of this flag as described above.
(From OE-Core rev: c5d499693672ec9619392011b765941cf94aa319)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit 05ef4f2a7b225c8d230eaca8d333ffb921729d79 removed this
functionality by accident. It was implemented in text exporter, while it
should have been a global feature independent on exporter type to avoid
such accidental deletion.
(From OE-Core rev: 2996b11596afca288a6b7f409a5287063d331f3b)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Cc: Marta Rybczynska <marta.rybczynska@ygreky.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
https://nvd.nist.gov/general/news/cvss-v4-0-official-support
CVSS v4.0 was released in November 2023
NVD announced support for it in June 2024
Current stats are:
* cvss v4 provided, but also v3, so cve-check showed a value
sqlite> select count(*) from nvd where scorev4 != 0.0 and scorev3 != 0.0;
2069
* only cvss v4 provided, so cve-check did not show any
sqlite> select count(*) from nvd where scorev4 != 0.0 and scorev3 = 0.0;
260
(From OE-Core rev: 358dbfcd80ae1fa414d294c865dd293670c287f0)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added the "modified" field to the JSON export in the
cve-check.class. This field captures the last modification date of each
CVE, providing more detailed information on changes and updates within
the exported data.
(From OE-Core rev: 740b8a0b23c4021d07c3714420e3ea8b46e61454)
Signed-off-by: Katawann <quent_55@hotmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove the TEXT format support, as the JSON format offers more functions.
Users who do automation should have migrated already.
Support of both formats makes the code more complex than necessary.
Users can convert JSON files to TEXT files with cve-json-to-text.py
in scripts/
(From OE-Core rev: 05ef4f2a7b225c8d230eaca8d333ffb921729d79)
Signed-off-by: Marta Rybczynska <marta.rybczynska@ygreky.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add status information for each CVE under analysis.
Previously the information passed between different function of the
cve-check class included only tables of patched, unpatched, ignored
vulnerabilities and the general status of the recipe.
The VEX work requires more information, and we need to pass them
between different functions, so that it can be enriched as the
analysis progresses. Instead of multiple tables, use a single one
with annotations for each CVE encountered. For example, a patched
CVE will have:
{"abbrev-status": "Patched", "status": "version-not-in-range"}
abbrev-status contains the general status (Patched, Unpatched,
Ignored and Unknown that will be added in the VEX code)
status contains more detailed information that can come from
CVE_STATUS and the analysis.
Additional fields of the annotation include for example the name
of the patch file fixing a given CVE.
We also use the annotation in CVE_STATUS to filter out entries
that do not apply to the given recipe
(From OE-Core rev: 452e605b55ad61c08f4af7089a5a9c576ca28f7d)
Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com>
Signed-off-by: Samantha Jalabert <samantha.jalabert@syslinbit.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVE_STATUS contains assesment of a given CVE, but until now it didn't have
include the affected vendor/product. In the case of a global system include,
that CVE_STATUS was visible in all recipes.
This patch allows encoding of affected product/vendor to each CVE_STATUS
assessment, also for groups. We can then filter them later and use only
CVEs that correspond to the recipe.
This is going to be used in meta/conf/distro/include/cve-extra-exclusions.inc
and similar places.
(From OE-Core rev: abca80a716e92fc18d3085aba1a15f4bac72379c)
Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rtaher than trying to use a sqlite database over NFS from DL_DIR, work from
a local copy in STAGING DIR after fetching.
(From OE-Core rev: 03596904392d257572a905a182b92c780d636744)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The variable contains the suffix of the CVE JSON manifest file.
By default, this variable is set to 'json', so the current behavior
is not changed, but enables developers to use some other suffix,
e.g., cve.json (similar to spdx.json).
(From OE-Core rev: d99eee76923659c0b95bf9ef415ae5d44f736d01)
Signed-off-by: Aleksandar Nikolic <an010@live.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Log if the CVE_STATUS is set for a CVE, but the cve is not reported for a
component. This should hopefully help to clean up not needed CVE_STATUS
settings.
(From OE-Core rev: 013d531a84fa08b6ae8a47bdf3ba1fa8f18ba270)
Signed-off-by: Simone Weiß <simone.p.weiss@posteo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This change introduced a warning if version comparisons failed, but
this is far too common an issue in data that we don't control, so this
shouldn't cause a warning:
WARNING: automake-native-1.16.5-r0 do_cve_check: automake: Failed to compare 1.16.5 = branch_1-9 for CVE-2009-4029
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m1 for CVE-2010-4539
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m2 for CVE-2010-4539
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m3 for CVE-2010-4539
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m4\/m5 for CVE-2010-4539
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m1 for CVE-2010-4644
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m2 for CVE-2010-4644
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m3 for CVE-2010-4644
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m4\/m5 for CVE-2010-4644
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m1 for CVE-2011-0715
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m2 for CVE-2011-0715
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m3 for CVE-2011-0715
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m4\/m5 for CVE-2011-0715
WARNING: automake-1.16.5-r0 do_cve_check: automake: Failed to compare 1.16.5 = branch_1-9 for CVE-2009-4029
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s for CVE-2003-0577
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s for CVE-2004-0982
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s for CVE-2004-1284
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s_r11 for CVE-2006-3355
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s for CVE-2007-0578
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s_r11 for CVE-2007-0578
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s for CVE-2009-1301
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s_r11 for CVE-2009-1301
This reverts commit a1989e4197178c2431ceca499e0b4876b233b131.
(From OE-Core rev: c7c7dbdd5474002cfd9ec24864e77a0df2b790ea)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Judgment processing of vulnerable using "=" compares characters as strings rather than numbers,
and misjudges "cases that do not match in strings but do match in numbers" as "Patched".
(e.g. PV = "1.2.0" and Vulnerabilities Affected Versions (registered with NVD) = "1.2")
Therefore, if the comparison operator used in the judgment processing of vulnerable is "=",
add numeric comparison processing.
(From OE-Core rev: a1989e4197178c2431ceca499e0b4876b233b131)
Signed-off-by: Shinji Matsunaga <shin.matsunaga@fujitsu.com>
Signed-off-by: Shunsuke Tokumoto <s-tokumoto@fujitsu.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The JSON report generated by the cve-check class is basically a huge
list of packages. This list of packages is, however, unsorted.
To make things easier for people comparing the JSON, or more
specifically for git when archiving the JSON over time in a git
repository, we can sort the list by package name.
(From OE-Core rev: e9861be0e5020830c2ecc24fd091f4f5b05da036)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows building detailed vulnerability analysis tools without
relying on external resources.
(From OE-Core rev: 048ff0ad927f4d37cc5547ebeba9e0c221687ea6)
Signed-off-by: Antoine Lubineau <antoine.lubineau@easymile.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Originally these were shell functions but they have long since been processed by
bb.build.exec_func(). Since we no longer need shell syntax, we can drop the ';'
delimiters and just use a space separated string.
This cleans up the variable and quietly removes any stray ';' that do happen to
still make it in.
(From OE-Core rev: c3365dfd9ddd7fbe70b62e0f11166e57a8ca6f73)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
The CVE_STATUS should contain an information about status wich
is decoded in 3 items:
- generic status: "Ignored", "Patched" or "Unpatched"
- more detailed status enum
- description: free text describing reason for status
Examples of usage:
CVE_STATUS[CVE-1234-0001] = "not-applicable-platform: Issue only applies on Windows"
CVE_STATUS[CVE-1234-0002] = "fixed-version: Fixed externally"
CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
(From OE-Core rev: 34f682a24b7075b12ec308154b937ad118d69fe5)
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* ${IMAGE_NAME}${IMAGE_NAME_SUFFIX} is almost always used together already
and when they aren't it's usually because of hardcoded '.rootfs' suffix
* it's a bit strange, because ${IMAGE_NAME_SUFFIX} is applied after the
version from ${IMAGE_VERSION_SUFFIX}, if we move it to ${IMAGE_LINK_NAME}
then it will be applied before the version and ${IMAGE_LINK_NAME}
will be just the version-less symlink to latest built version.
* it's not added to INITRAMFS_IMAGE_NAME as it assumes that all
images used as initramfs will set IMAGE_NAME_SUFFIX to empty.
Many already do as shown bellow, but you might need to extend
this list in your layer.
* this also allows to drop support for imgsuffix varflag, recipes which
don't want to have .rootfs suffix can just set IMAGE_NAME_SUFFIX to
empty and it will be consistently respected by both IMAGE_NAME and IMAGE_LINK_NAME
* imgsuffix = d.getVarFlag("do_" + taskname, 'imgsuffix') or d.expand("${IMAGE_NAME_SUFFIX}.")
is kind of terrible, notice trailing '.' after ${IMAGE_NAME_SUFFIX}
while this dot was in imgsuffix in:
do_bootimg[imgsuffix] = "."
but in both cases it's not really part of the imgsuffix, but the
"extension" type separator as in dst variable:
dst = os.path.join(deploy_dir, link_name + "." + type)
- src = img_name + imgsuffix + type
+ src = img_name + "." + type
* for ubifs volumes move vname after IMAGE_NAME_SUFFIX
* to better document these changes here is an example with default poky
configuration with just:
IMAGE_FSTYPES:append:pn-core-image-minimal = " live wic wic.vmdk ubi"
MKUBIFS_ARGS = "-m 2048 -e 129024 -c 968 -x zlib"
UBINIZE_ARGS = "-m 2048 -p 131072 -s 512"
added in local.conf, so that deploy_dir has also some initramfs and more
IMAGE_FSTYPES
* "ls -lahi tmp/deploy/images/qemux86-64/"
output after "bitbake core-image-minimal"
And deploy-dir is cleaned between runs with:
bitbake -c clean core-image-minimal core-image-minimal-initramfs virtual/kernel grub-efi systemd-boot
The output confirms that the only change is ".rootfs" added not only
in ext4 and manifest files, but also for hddimg, iso, qemuboot.conf
testdata.json for both the actual artifacts as well as the symlinks
while core-image-minimal-initramfs doesn't have them as IMAGE_NAME_SUFFIX
was already set to empty there:
meta/classes-recipe/baremetal-image.bbclass:IMAGE_NAME_SUFFIX ?= ""
meta/recipes-core/images/core-image-minimal-initramfs.bb:IMAGE_NAME_SUFFIX ?= ""
meta/recipes-core/images/core-image-tiny-initramfs.bb:IMAGE_NAME_SUFFIX ?= ""
meta/recipes-extended/baremetal-example/baremetal-helloworld_git.bb:IMAGE_NAME_SUFFIX ?= ""
meta/recipes-extended/images/core-image-testcontroller-initramfs.bb:IMAGE_NAME_SUFFIX ?= ""
before these changes:
total 297M
31269162 drwxr-xr-x 2 martin martin 4.0K Mar 7 19:19 .
31263942 drwxr-xr-x 3 martin martin 4.0K Mar 7 12:53 ..
35845703 lrwxrwxrwx 2 martin martin 77 Mar 7 12:27 bzImage -> bzImage--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.bin
35845704 -rw-r--r-- 2 martin martin 11M Mar 7 12:27 bzImage--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.bin
35845702 lrwxrwxrwx 2 martin martin 77 Mar 7 12:27 bzImage-qemux86-64.bin -> bzImage--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.bin
40236967 -rw-r--r-- 2 martin martin 13M Mar 7 19:19 core-image-minimal-initramfs-qemux86-64-20230307181808.cpio.gz
40203232 -rw-r--r-- 2 martin martin 1.1K Mar 7 19:19 core-image-minimal-initramfs-qemux86-64-20230307181808.manifest
40212700 -rw-r--r-- 2 martin martin 1.6K Mar 7 19:19 core-image-minimal-initramfs-qemux86-64-20230307181808.qemuboot.conf
40211556 -rw-r--r-- 2 martin martin 211K Mar 7 19:19 core-image-minimal-initramfs-qemux86-64-20230307181808.testdata.json
40236964 lrwxrwxrwx 2 martin martin 62 Mar 7 19:19 core-image-minimal-initramfs-qemux86-64.cpio.gz -> core-image-minimal-initramfs-qemux86-64-20230307181808.cpio.gz
40203235 lrwxrwxrwx 2 martin martin 63 Mar 7 19:19 core-image-minimal-initramfs-qemux86-64.manifest -> core-image-minimal-initramfs-qemux86-64-20230307181808.manifest
40212690 lrwxrwxrwx 2 martin martin 68 Mar 7 19:19 core-image-minimal-initramfs-qemux86-64.qemuboot.conf -> core-image-minimal-initramfs-qemux86-64-20230307181808.qemuboot.conf
40211560 lrwxrwxrwx 2 martin martin 68 Mar 7 19:19 core-image-minimal-initramfs-qemux86-64.testdata.json -> core-image-minimal-initramfs-qemux86-64-20230307181808.testdata.json
40237307 -rw-r--r-- 2 martin martin 57M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.hddimg
40237329 -rw-r--r-- 2 martin martin 56M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.iso
40220347 -rw-r--r-- 2 martin martin 1.6K Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.qemuboot.conf
40236942 -rw-r--r-- 2 martin martin 34M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.rootfs.ext4
40211563 -rw-r--r-- 2 martin martin 1.2K Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.rootfs.manifest
40237206 -rw-r--r-- 2 martin martin 16M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.rootfs.tar.bz2
40237216 -rw-r--r-- 2 martin martin 20M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.rootfs.ubi
40224358 -rw-r--r-- 2 martin martin 19M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.rootfs.ubifs
40360386 -rw-r--r-- 2 martin martin 73M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.rootfs.wic
40237285 -rw-r--r-- 2 martin martin 35M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.rootfs.wic.vmdk
40209866 -rw-r--r-- 2 martin martin 206K Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.testdata.json
40236946 lrwxrwxrwx 2 martin martin 56 Mar 7 19:19 core-image-minimal-qemux86-64.ext4 -> core-image-minimal-qemux86-64-20230307181808.rootfs.ext4
40237336 lrwxrwxrwx 2 martin martin 51 Mar 7 19:19 core-image-minimal-qemux86-64.hddimg -> core-image-minimal-qemux86-64-20230307181808.hddimg
40237337 lrwxrwxrwx 2 martin martin 48 Mar 7 19:19 core-image-minimal-qemux86-64.iso -> core-image-minimal-qemux86-64-20230307181808.iso
40211564 lrwxrwxrwx 2 martin martin 60 Mar 7 19:19 core-image-minimal-qemux86-64.manifest -> core-image-minimal-qemux86-64-20230307181808.rootfs.manifest
40220348 lrwxrwxrwx 2 martin martin 58 Mar 7 19:19 core-image-minimal-qemux86-64.qemuboot.conf -> core-image-minimal-qemux86-64-20230307181808.qemuboot.conf
40237205 lrwxrwxrwx 2 martin martin 59 Mar 7 19:19 core-image-minimal-qemux86-64.tar.bz2 -> core-image-minimal-qemux86-64-20230307181808.rootfs.tar.bz2
40209873 lrwxrwxrwx 2 martin martin 58 Mar 7 19:19 core-image-minimal-qemux86-64.testdata.json -> core-image-minimal-qemux86-64-20230307181808.testdata.json
40237217 lrwxrwxrwx 2 martin martin 55 Mar 7 19:19 core-image-minimal-qemux86-64.ubi -> core-image-minimal-qemux86-64-20230307181808.rootfs.ubi
40236771 lrwxrwxrwx 2 martin martin 57 Mar 7 19:19 core-image-minimal-qemux86-64.ubifs -> core-image-minimal-qemux86-64-20230307181808.rootfs.ubifs
40237287 lrwxrwxrwx 2 martin martin 55 Mar 7 19:19 core-image-minimal-qemux86-64.wic -> core-image-minimal-qemux86-64-20230307181808.rootfs.wic
40237286 lrwxrwxrwx 2 martin martin 60 Mar 7 19:19 core-image-minimal-qemux86-64.wic.vmdk -> core-image-minimal-qemux86-64-20230307181808.rootfs.wic.vmdk
40237192 -rw-r--r-- 2 martin martin 3.8K Mar 7 19:19 core-image-minimal.env
34458377 -rw-r--r-- 2 martin martin 616K Mar 7 17:55 grub-efi-bootx64.efi
34963606 -rwxr-xr-x 2 martin martin 103K Mar 6 22:02 linuxx64.efi.stub
35845662 -rw-r--r-- 2 martin martin 8.2M Mar 7 12:27 modules--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.tgz
35845701 lrwxrwxrwx 2 martin martin 77 Mar 7 12:27 modules-qemux86-64.tgz -> modules--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.tgz
34963605 -rwxr-xr-x 2 martin martin 140K Mar 6 22:02 systemd-bootx64.efi
27651415 -rw-r--r-- 2 martin martin 274 Mar 7 19:19 ubinize-core-image-minimal-qemux86-64-20230307181808.cfg
after these changes:
total 297M
31269162 drwxr-xr-x 2 martin martin 4.0K Mar 7 19:16 .
31263942 drwxr-xr-x 3 martin martin 4.0K Mar 7 12:53 ..
39479266 lrwxrwxrwx 2 martin martin 77 Mar 7 12:27 bzImage -> bzImage--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.bin
39479267 -rw-r--r-- 2 martin martin 11M Mar 7 12:27 bzImage--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.bin
39479264 lrwxrwxrwx 2 martin martin 77 Mar 7 12:27 bzImage-qemux86-64.bin -> bzImage--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.bin
39648810 -rw-r--r-- 2 martin martin 13M Mar 7 19:15 core-image-minimal-initramfs-qemux86-64-20230307181456.cpio.gz
39638400 -rw-r--r-- 2 martin martin 1.1K Mar 7 19:15 core-image-minimal-initramfs-qemux86-64-20230307181456.manifest
39644650 -rw-r--r-- 2 martin martin 1.6K Mar 7 19:15 core-image-minimal-initramfs-qemux86-64-20230307181456.qemuboot.conf
39637657 -rw-r--r-- 2 martin martin 211K Mar 7 19:15 core-image-minimal-initramfs-qemux86-64-20230307181456.testdata.json
39648091 lrwxrwxrwx 2 martin martin 62 Mar 7 19:15 core-image-minimal-initramfs-qemux86-64.cpio.gz -> core-image-minimal-initramfs-qemux86-64-20230307181456.cpio.gz
39638401 lrwxrwxrwx 2 martin martin 63 Mar 7 19:15 core-image-minimal-initramfs-qemux86-64.manifest -> core-image-minimal-initramfs-qemux86-64-20230307181456.manifest
39644651 lrwxrwxrwx 2 martin martin 68 Mar 7 19:15 core-image-minimal-initramfs-qemux86-64.qemuboot.conf -> core-image-minimal-initramfs-qemux86-64-20230307181456.qemuboot.conf
39637662 lrwxrwxrwx 2 martin martin 68 Mar 7 19:15 core-image-minimal-initramfs-qemux86-64.testdata.json -> core-image-minimal-initramfs-qemux86-64-20230307181456.testdata.json
39654281 -rw-r--r-- 2 martin martin 34M Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.ext4
39656710 -rw-r--r-- 2 martin martin 57M Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.hddimg
39657112 -rw-r--r-- 2 martin martin 56M Mar 7 19:16 core-image-minimal-qemux86-64.rootfs-20230307181456.iso
39645313 -rw-r--r-- 2 martin martin 1.2K Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.manifest
39646013 -rw-r--r-- 2 martin martin 1.6K Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.qemuboot.conf
39656336 -rw-r--r-- 2 martin martin 16M Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.tar.bz2
39644408 -rw-r--r-- 2 martin martin 206K Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.testdata.json
39656583 -rw-r--r-- 2 martin martin 20M Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.ubi
39654124 -rw-r--r-- 2 martin martin 19M Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.ubifs
39802371 -rw-r--r-- 2 martin martin 73M Mar 7 19:16 core-image-minimal-qemux86-64.rootfs-20230307181456.wic
39657113 -rw-r--r-- 2 martin martin 35M Mar 7 19:16 core-image-minimal-qemux86-64.rootfs-20230307181456.wic.vmdk
39654412 lrwxrwxrwx 2 martin martin 56 Mar 7 19:15 core-image-minimal-qemux86-64.rootfs.ext4 -> core-image-minimal-qemux86-64.rootfs-20230307181456.ext4
39657167 lrwxrwxrwx 2 martin martin 58 Mar 7 19:16 core-image-minimal-qemux86-64.rootfs.hddimg -> core-image-minimal-qemux86-64.rootfs-20230307181456.hddimg
39657168 lrwxrwxrwx 2 martin martin 55 Mar 7 19:16 core-image-minimal-qemux86-64.rootfs.iso -> core-image-minimal-qemux86-64.rootfs-20230307181456.iso
39645316 lrwxrwxrwx 2 martin martin 60 Mar 7 19:15 core-image-minimal-qemux86-64.rootfs.manifest -> core-image-minimal-qemux86-64.rootfs-20230307181456.manifest
39646014 lrwxrwxrwx 2 martin martin 65 Mar 7 19:15 core-image-minimal-qemux86-64.rootfs.qemuboot.conf -> core-image-minimal-qemux86-64.rootfs-20230307181456.qemuboot.conf
39656315 lrwxrwxrwx 2 martin martin 59 Mar 7 19:15 core-image-minimal-qemux86-64.rootfs.tar.bz2 -> core-image-minimal-qemux86-64.rootfs-20230307181456.tar.bz2
39644406 lrwxrwxrwx 2 martin martin 65 Mar 7 19:15 core-image-minimal-qemux86-64.rootfs.testdata.json -> core-image-minimal-qemux86-64.rootfs-20230307181456.testdata.json
39656584 lrwxrwxrwx 2 martin martin 55 Mar 7 19:15 core-image-minimal-qemux86-64.rootfs.ubi -> core-image-minimal-qemux86-64.rootfs-20230307181456.ubi
39654775 lrwxrwxrwx 2 martin martin 57 Mar 7 19:15 core-image-minimal-qemux86-64.rootfs.ubifs -> core-image-minimal-qemux86-64.rootfs-20230307181456.ubifs
39657126 lrwxrwxrwx 2 martin martin 55 Mar 7 19:16 core-image-minimal-qemux86-64.rootfs.wic -> core-image-minimal-qemux86-64.rootfs-20230307181456.wic
39657088 lrwxrwxrwx 2 martin martin 60 Mar 7 19:16 core-image-minimal-qemux86-64.rootfs.wic.vmdk -> core-image-minimal-qemux86-64.rootfs-20230307181456.wic.vmdk
39654418 -rw-r--r-- 2 martin martin 3.8K Mar 7 19:15 core-image-minimal.env
39475732 -rw-r--r-- 2 martin martin 616K Mar 7 17:55 grub-efi-bootx64.efi
31507074 -rwxr-xr-x 2 martin martin 103K Mar 6 22:02 linuxx64.efi.stub
39479261 -rw-r--r-- 2 martin martin 8.2M Mar 7 12:27 modules--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.tgz
39479263 lrwxrwxrwx 2 martin martin 77 Mar 7 12:27 modules-qemux86-64.tgz -> modules--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.tgz
31507058 -rwxr-xr-x 2 martin martin 140K Mar 6 22:02 systemd-bootx64.efi
27651415 -rw-r--r-- 2 martin martin 274 Mar 7 19:15 ubinize-core-image-minimal-qemux86-64.rootfs-20230307181456.cfg
[YOCTO #12937]
(From OE-Core rev: 26d97acc71379ab6702fa54a23b6542a3f51779c)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add new fetcher for the NVD database using the 2.0 API [1].
The implementation changes as little as possible, keeping the current
database format (but using a different database file for the transition
period), with a notable exception of not using the META table.
Minor changes that could be visible:
- the database starts in 1999 instead of 2002
- the complete fetch is longer (30 minutes typically)
[1] https://nvd.nist.gov/developers/vulnerabilities
(From OE-Core rev: fb62c4c3dbca4e58f7ce6cf29d4b630a06411a97)
Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
NVD DB store version and update in the same value, separated by '_'.
The proposed patch check if the version from NVD DB contains a "_",
ie 9.2.0_p1 is convert to 9.2.0p1 before version comparison.
[YOCTO #14127]
Reviewed-by: Yoann CONGAL <yoann.congal@smile.fr>
(From OE-Core rev: 7d00f6ec578084a0a0e5caf36241d53036d996c4)
Signed-off-by: Geoffrey GIRY <geoffrey.giry@smile.fr>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building an image cve_check_write_rootfs_manifest() would sometimes fail
with a FileNotFoundError when writing the manifest.cve due to the parent
directory (DEPLOY_DIR_IMAGE) not (yet) existing.
The image task will provide the manifest in the deploy directory afterwards,
so other recipes depending on the manifest being in DEPLOY_DIR_IMAGE should
continue to function properly.
(From OE-Core rev: 00fb2aae22ce0d7ff5f3f8766fa770eeb4e73483)
Signed-off-by: Jermain Horsman <jermain.horsman@nedap.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We can have multiple processes reading the database at the same time, and
cursors only release their locks when they're garbage collected.
This might be the cause of random sqlite errors on the autobuilder, so
explicitly close the cursors when we're done with them.
(From OE-Core rev: 5d2e90e4a58217a943ec21140bc2ecdd4357a98a)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The CVE check database needs to have a shared lock acquired on it before
it is accessed. This to prevent cve-update-db-native from deleting the
database file out from underneath it.
[YOCTO #14899]
(From OE-Core rev: 20a9911b73df62a0d0d1884e57085f13ac5016dd)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As stated in our top level license files, the license is MIT unless
otherwise stated. Add SPDX identifers accordingly. Replace older
license statementa with the standardised syntax. Also drop "All
Rights Reserved" expression as it isn't used now, doesn't mean anything
and is confusing.
(From OE-Core rev: 081a391fe09a21265881e39a2a496e4e10b4f80b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Where there isn't a copyright statement, add one to make it explicit.
Also drop editor config lines where they were present.
(From OE-Core rev: 880c1ea3edc8edef974e65b2d424fc36809ea034)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The cve-check class writes temporary files to preserve state across the
build, and cleans them up in a CookerExit handler.
However, in memory-resident builds the cooker won't exit in between
builds, so the state isn't cleared and the CVE report generation fails:
NOTE: Generating JSON CVE summary
ERROR: Error adding the same package twice
Easily solved by hooking to BuildCompleted, instead of CookerExit.
(From OE-Core rev: fccdcfd301de281a427bfee48d8ff47fa07b7259)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ignored CVEs aren't patched, but do not apply in our configuration
for some reason. Up till now they were only partially supported
and reported as "Patched".
This patch adds separate reporting of Ignored CVEs. The variable
CVE_CHECK_REPORT_PATCHED now manages reporting of both patched
and ignored CVEs.
(From OE-Core rev: c773102d4828fc4ddd1024f6115d577e23f1afe4)
Signed-off-by: Marta Rybczynska <marta.rybczynska@huawei.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make empty return types in check_cvs the same for all code paths.
(From OE-Core rev: f86393c93dec47b24e837d0c4c5761a716ecdbb6)
Signed-off-by: Marta Rybczynska <marta.rybczynska@huawei.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the cve-check text mode output, we didn't write fragment
files if there are no CVEs (if CVE_CHECK_REPORT_PATCHED is 1),
or no unpached CVEs otherwise.
However, in a system after multiple builds,
cve_check_write_rootfs_manifest might find older files and use
them as current, what leads to incorrect reporting.
Fix it by always writing a fragment file, even if empty.
(From OE-Core rev: f1b7877acd0f6e3626faa57d9f89809cfcdfd0f1)
Signed-off-by: Marta Rybczynska <marta.rybczynska@huawei.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move the function to a library, it could be useful in other places.
(From OE-Core rev: debd37abcdde8788761ebdb4a05bc61f7394cbb8)
Signed-off-by: Marta Rybczynska <marta.rybczynska@huawei.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When running CVE checks in CI we're usually not interested in warnings on the
console for any CVEs present. Add a configuration option CVE_CHECK_SHOW_WARNINGS
to allow this to be disabled (it is left enabled by default).
(From OE-Core rev: 1054d3366ba528f2ad52585cf951e508958c5c68)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Before this the rootfs manifest and the summary were identical.
We should separate the summary and rootfs manifest more clearly,
now the summary is for all CVEs and the rootfs manifest is only for
things in that image. This is even more useful if you build multiple
images.
(From OE-Core rev: 3b8cc6fc45f0ea5677729ee2b1819bdc7a441ab1)
Signed-off-by: Ernst Sjöstrand <ernstp@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As product, sdk should do cve check as well as rootfs.
(From OE-Core rev: cc17753935c5f9e08aaa6c5886f059303147c07b)
Signed-off-by: Lei Maohui <leimaohui@fujitsu.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The addition of summary output caused two issues: error when building
an image and the fact that JSON output was generated even when
CVE_CHECK_FORMAT_JSON.
When generating an image it caused an error like:
ERROR: core-image-minimal-1.0-r0 do_rootfs: Error executing a python function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:cve_check_write_rootfs_manifest(d)
0003:
File: '/home/alexk/poky/meta/classes/cve-check.bbclass', lineno: 213, function: cve_check_write_rootfs_manifest
0209:
0210: link_path = os.path.join(deploy_dir, "%s.json" % link_name)
0211: manifest_path = d.getVar("CVE_CHECK_MANIFEST_JSON")
0212: bb.note("Generating JSON CVE manifest")
*** 0213: generate_json_report(json_summary_name, json_summary_link_name)
0214: bb.plain("Image CVE JSON report stored in: %s" % link_path)
0215:}
0216:
0217:ROOTFS_POSTPROCESS_COMMAND:prepend = "${@'cve_check_write_rootfs_manifest; ' if d.getVar('CVE_CHECK_CREATE_MANIFEST') == '1' else ''}"
Exception: NameError: name 'json_summary_name' is not defined
The fix is to pass the d variable to the pure python function generate_json_report
to get correct values of variables and add conditions for the JSON
output where needed.
In addition clarify the message presenting the summary JSON file,
which isn't related to an image.
Uses partial fixes from Alex Kiernan, Ernst Sjöstrand (ernstp),
and Davide Gardenal.
Fixes: f2987891d315 ("cve-check: add JSON format to summary output")
(From OE-Core rev: 9015dec93233c7d45fd0c9885ff5d4ec23ad377d)
Signed-off-by: Marta Rybczynska <marta.rybczynska@huawei.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
An if statement now checks if the link and output path are
the same, if they are then the link is not created,
otherwise it is.
(From OE-Core rev: 2f024c0236c4806f0e59e4ce51a42f6b80fdf1b3)
Signed-off-by: Davide Gardenal <davide.gardenal@huawei.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create generate_json_report including all the code used to generate the JSON
manifest file.
Add to cve_save_summary_handler the ability to create the summary in JSON format.
(From OE-Core rev: f2987891d315466b7ef180ecce81d15320ce8487)
Signed-off-by: Davide Gardenal <davide.gardenal@huawei.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The only part of the cve-check task which needs files is the patch
examination, and typically these patches are local so fetch isn't needed.
(From OE-Core rev: 2c9b3186d3b7c18cbea239ab9b06e85b7c243b54)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Until now the CVE checker was giving information about CVEs found for
a product (or more products) contained in a recipe. However, there was
no easy way to find out which products or recipes have no CVEs. Having
no reported CVEs might mean there are simply none, but can also mean
a product name (CPE) mismatch.
This patch adds CVE_CHECK_COVERAGE option enabling a new type of
statistics. Then we use the new JSON format to report the information.
The legacy text mode report does not contain it.
This option is expected to help with an identification of recipes with
mismatched CPEs, issues in the database and more.
This work is based on [1], but adding the JSON format makes it easier
to implement, without additional result files.
[1] https://lists.openembedded.org/g/openembedded-core/message/159873
(From OE-Core rev: d1849a1facd64fa0bcf8336a0ed5fbf71b2e3cb5)
Signed-off-by: Marta Rybczynska <marta.rybczynska@huawei.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add an option to output the CVE check in a JSON-based format.
This format is easier to parse in software than the original
text-based one and allows post-processing by other tools.
Output formats are now handed by CVE_CHECK_FORMAT_TEXT and
CVE_CHECK_FORMAT_JSON. Both of them are enabled by default.
The JSON output format gets generated in a similar way to the
text format with the exception of the manifest: appending to
JSON arrays requires parsing the file. Because of that we
first write JSON fragments and then assemble them in one pass
at the end.
(From OE-Core rev: df567de36ae5964bee433ebb97e8bf702034994a)
Signed-off-by: Marta Rybczynska <marta.rybczynska@huawei.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that all of the functions in cve-check open the database read-only,
we can remove this lockfile.
This means cve-check can run in parallal again, improving runtimes
massively.
This reverts commit d55fbf4779.
(From OE-Core rev: d3d3e7b324698ec3e6fce1951aba389805f3edd3)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All of the function in cve-check should open the database read-only, as
the only writer is the fetch task in cve-update-db. However,
get_cve_info() was failing to do this, which might be causing locking
issues with sqlite.
(From OE-Core rev: 8de517238f1f418d9af1ce312d99de04ce2e26fc)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create directory of the CVE_CHECK_MANIFEST variable before copy to it,
so that the variable can use an arbitrary directory name.
(From OE-Core rev: 9829c16301bf2dce39fa046401a984f112fa0322)
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
this should prevent running into the very rare error
sqlite3.OperationalError: attempt to write a readonly database
As highlighted by https://www.sqlite.org/faq.html#q5
it is likely that the adapter won't allow use multiple exec calls
at the same time.
So it's best to prevent multiple accesses at a time, by reusing
the already in place CVE_CHECK_DB_FILE_LOCK
YOCTO #14110
(From OE-Core rev: 677f5741bd265be49d4a5bb933b3e8d8c4eec653)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Moving the function will allow other classes to capture which CVEs have
been patched, in particular SBoM generation.
Also add a function to capture the CPE ID from the CVE Product and
Version
(From OE-Core rev: 75d34259a715120be1d023e4fd7b6b4b125f2443)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This variable has been deprecated since Yocto Project version 3.0.
(From OE-Core rev: f8ac58568b2dceef54a743369460019b3a3eeccd)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
