linux/poky.git/meta/classes, branch 5.1_M3

cve-check: remove the TEXT format support

2024-08-25T14:36:30+00:00

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 Signed-off-by: Richard Purdie

vex.bbclass: add a new class

2024-08-20T13:12:40+00:00

The "vex" class generates the minimum information that is necessary for VEX generation by an external CVE checking tool. It is a drop-in replacement of "cve-check". It uses the same variables from recipes to make the migration and backporting easier. The goal of this class is to allow generation of the CVE list of an image or distribution on-demand, including the latest information from vulnerability databases. Vulnerability data changes every day, so a status generated at build becomes out-of-date very soon. Research done for this work shows that the current VEX formats (CSAF and OpenVEX) do not provide enough information to generate such rolling information. Instead, we extract the needed data from recipe annotations (package names, CPEs, versions, CVE patches applied...) and store for later use in the format that is an extension of the CVE-check JSON output format. This output can be then used (separately or with SPDX of the same build) by an external tool to generate the vulnerability annotation and VEX statements in standard formats. (From OE-Core rev: 6352ad93a72e67d6dfa82e870222518a97c426fa) Signed-off-by: Marta Rybczynska Signed-off-by: Samantha Jalabert Signed-off-by: Richard Purdie

cve-check: annotate CVEs during analysis

2024-08-20T13:12:40+00:00

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 Signed-off-by: Samantha Jalabert Signed-off-by: Richard Purdie

cve-check: encode affected product/vendor in CVE_STATUS

2024-08-20T13:12:40+00:00

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 Signed-off-by: Richard Purdie

archiver.bbclass: fix BB_GENERATE_MIRROR_TARBALLS checking

2024-08-09T21:33:38+00:00

The variable 'have_mirror_tarballs' is used as a boolean while it is actually the result of 'd.getVar('BB_GENERATE_MIRROR_TARBALLS')' and thus a string. Fix this by converting it into a boolean before using i t. (From OE-Core rev: f6185d51b84d8d2eb578dbd322c1c61537efabf6) Signed-off-by: Enrico Jörns Signed-off-by: Richard Purdie

sdpx: Avoid loading of SPDX_LICENSE_DATA into global config

2024-08-07T14:47:15+00:00

Loading a load of json files into a memory structure and stashing in a bitbake variable is relatively anti-social making bitbake -e output hard to read for example as well as other potential performance issues. Defer loading of that data until it is actually needed/used in a funciton where it is now passed as a parameter. (From OE-Core rev: 6f21cc9598178288784ff451ab3c40b174c0ef3e) Signed-off-by: Richard Purdie

buildhistory: Restoring files from preserve list

2024-08-07T14:47:15+00:00

This fix will ensure that, when we activate feature `BUILDHISTORY_RESET`, files marked to keep on feature `BUILDHISTORY_PRESERVE` will indeed exist is buildhistory final path since they are moved to buildhistory/old but not restored at any point. (From OE-Core rev: 9f68a45aa238ae5fcdfaca71ba0e7015e9cb720e) Signed-off-by: Pedro Ferreira Signed-off-by: Richard Purdie

buildhistory: Fix intermittent package file list creation

2024-08-07T14:47:15+00:00

The directory that buildhistory_list_pkg_files writes to during do_package is created by do_packagedata so a clean buildhistory doesn't have files-in-package written during the first build since packagedata happens after do_package. Ensure the output package folder is created to avoid missing files-in-package.txt files. Also it ensures that in case of `find` fails we leave with a hard error instead of hiding the error on the for loop. (From OE-Core rev: 8de9b8c1e199896b9a7bc5ed64967c6bfbf84bea) Signed-off-by: Pedro Silva Ferreira Signed-off-by: Richard Purdie

cve_check: Use a local copy of the database during builds

2024-08-05T13:31:57+00:00

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

create-spdx-3.0/populate_sdk_base: Add SDK_CLASSES inherit mechanism to fix tarball SPDX manifests

2024-07-26T11:28:42+00:00

Currently, "tarball" sdk based recipes don't generate SPDX manifests as they don't include the rootfs generation classes. Split the SPDX 3.0 image class into two so the SDK components can be included where needed. To do this, introduce an SDK_CLASSES variable similar to IMAGE_CLASSES which the SDK code can use. Migrate testsdk usage to this. Also move the image/sdk spdx classes to classes-recipe rather than the general classes directory since they'd never be included on a global level. For buildtools-tarball, it has its own testsdk functions so disable the class there as a deferred inherit would overwrite it. (From OE-Core rev: 662396533177b72cc1d83e95841b27f7e42dcb20) Signed-off-by: Richard Purdie