linux/poky.git/meta/classes, branch scarthgap-5.0.15

spdx30_tasks: Add support for exporting PACKAGECONFIG to SPDX

2025-12-31T15:49:31+00:00

Introduce the SPDX_INCLUDE_PACKAGECONFIG variable, which when enabled causes PACKAGECONFIG features to be recorded in the SPDX document as build parameters. Each feature is recorded as a DictionaryEntry with key PACKAGECONFIG: and value enabled or disabled, depending on whether the feature is active in the current build. This makes the build-time configuration more transparent in SPDX output and improves reproducibility tracking. This makes the build-time configuration more transparent in SPDX output and improves reproducibility tracking. In particular, it allows consumers of the SBOM to identify enabled/disabled features that may affect security posture or feature set. Reviewed-by: Joshua Watt (From OE-Core rev: 5cfd0690f819379d9f97c86d2078c3e529efe385) Signed-off-by: Kamel Bouhara (Schneider Electric) Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie (cherry picked from commit 7ec61ac40345a5c0ef1ce20513a4596989c91ef4) Signed-off-by: Steve Sakoman

kernel.bbclass: Add task to export kernel configuration to SPDX

2025-12-31T15:49:31+00:00

Introduce a new bitbake task do_create_kernel_config_spdx that extracts the kernel configuration from ${B}/.config and exports it into the recipe's SPDX document as a separate build_Build object. The kernel config parameters are stored as SPDX DictionaryEntry objects and linked to the main kernel build using an ancestorOf relationship. This enables the kernel build's configuration to be explicitly captured in the SPDX document for compliance, auditing, and reproducibility. The task is gated by SPDX_INCLUDE_KERNEL_CONFIG (default = "0"). Reviewed-by: Joshua Watt (From OE-Core rev: 1fff29a0428778929ffa530482ebf7db95f1e0ae) Signed-off-by: Kamel Bouhara (Schneider Electric) Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie (cherry picked from commit 228a968e7c47d811c06143279bdb0f9c5f374bef) Signed-off-by: Steve Sakoman

classes/create-spdx-2.2: Define SPDX_VERSION to 2.2

2025-12-17T16:48:37+00:00

SPDX_VERSION is used in DEPLOY_DIR_SPDX but if is not defined, will default to SPDX-1.1 Define SPDX_VERSION to have the correct deploy path, to align with master branch behaviour. The change in path was introduced in 8996d0899d CC: Kamel Bouhara (Schneider Electric) CC: JPEWhacker@gmail.com (From OE-Core rev: 04cc49593a0ba2c51e4f4d477d4587079735b624) Signed-off-by: Daniel Turull Signed-off-by: Steve Sakoman

vex: fix rootfs manifest

2025-12-01T15:34:55+00:00

Rootfs VEX file is created by gathering files from CVE_CHECK_DIR (deploy directory), however recipes generate the files only in CVE_CHECK_DIR (log directory). This make the rootfs VEX be always empty without any message. The code is copied from cve_check class, which writes to both, so let keep them aligned and make also vex write both files. Also add a warning for case that a cve file would be still missing. (From OE-Core rev: 7493eeed6d53bc704f558a0ccf8a0b5195381873) Signed-off-by: Peter Marko Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie (cherry picked from commit ee6541d0940c65685aaafd7d41a59a9406392e7d) Signed-off-by: Benjamin Robin (Schneider Electric) Signed-off-by: Steve Sakoman

spdx: extend CVE_STATUS variables

2025-12-01T15:34:55+00:00

If spdx is generated without inheriting cve/vex classes (which is poky default), only explicitly set CVE_STATUS fields are handled. Calculated ones (e.g. from CVE_STATUS_GROUPS) are ignored. Fix this by expanding the CVE_STATUS in spdx classes. (From OE-Core rev: 23a4e02542252657fa45fd4a605aec0af9178e0b) Signed-off-by: Peter Marko Signed-off-by: Richard Purdie (cherry picked from commit ead9c6a8770463c21210a57cc5320f44f7754dd3) Signed-off-by: Benjamin Robin (Schneider Electric) Signed-off-by: Steve Sakoman

cve-check: extract extending CVE_STATUS to library function

2025-12-01T15:34:55+00:00

The same code for extending CVE_STATUS by CVE_CHECK_IGNORE and CVE_STATUS_GROUPS is used on multiple places. Create a library function to have the code on single place and ready for reuse by additional classes. Conflicts: meta/classes/cve-check.bbclass meta/lib/oe/cve_check.py (From OE-Core rev: ddd295c7d4c313fbbb24f7a5e633d4adfea4054a) Signed-off-by: Peter Marko Signed-off-by: Richard Purdie (cherry picked from commit 45e18f4270d084d81c21b1e5a4a601ce975d8a77) Signed-off-by: Benjamin Robin (Schneider Electric) Signed-off-by: Steve Sakoman

vex.bbclass: add a new class

2025-12-01T15:34:55+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. When back-porting this feature, the do_generate_vex() had to be modified to use the "old" get_patched_cves() API. (From OE-Core rev: 123a60bc19987e99d511b1f515e118022949be7e) Signed-off-by: Marta Rybczynska Signed-off-by: Samantha Jalabert Signed-off-by: Richard Purdie (cherry picked from commit 6352ad93a72e67d6dfa82e870222518a97c426fa) Signed-off-by: Benjamin Robin (Schneider Electric) Signed-off-by: Steve Sakoman

spdx30: Provide software_packageUrl field in SPDX 3.0 SBOM

2025-11-26T15:50:35+00:00

Define var-SPDX_PACKAGE_URL to provide software_packageUrl field [1][2] in SPDX 3.0 SBOM, support to override with package name SPDX_PACKAGE_URL: Currently, the format of purl is not defined in Yocto, set empty for now until we have a comprehensive plan for what Yocto purls look like. But users could customize their own purl by setting var-SPDX_PACKAGE_URL [1] https://spdx.github.io/spdx-spec/v3.0.1/model/Software/Properties/packageUrl/ [2] https://spdx.github.io/spdx-spec/v3.0.1/annexes/pkg-url-specification/ (From OE-Core rev: c8e6953a0b6f59ffca994c440069db39e60b12d2) (From OE-Core rev: 60724efdb3a243bc796b390ad0c478584a0fb7fa) Signed-off-by: Hongxu Jia Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie Signed-off-by: Peter Marko Signed-off-by: Steve Sakoman

classes/create-spdx-2.2: Handle empty packages

2025-11-14T14:45:30+00:00

When combining an SPDX document, the package list might be empty (e.g. a baremetal image). Handle this case instead of erroring out (From OE-Core rev: 1f7326799c33d2a734c58d360773b87d7b86b0ec) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

classes/create-spdx-2.2: align DEPLOY_DIR_SPDX with SPDX_VERSION layout

2025-11-14T14:45:30+00:00

Upstream commit 544d46e4169a ("selftest/spdx: Fix for SPDX_VERSION addition") updated the selftests to expect SPDX artifacts under: ${DEPLOY_DIR}/spdx/${SPDX_VERSION}/ However, in this branch the effective SPDX output was still being written to: ${DEPLOY_DIR}/spdx/${PACKAGE_ARCH}/ without the version subdirectory. This caused SPDX selftests such as test_spdx_tar to fail with missing file errors, e.g.: AssertionError: .../deploy/spdx/SPDX-1.1/core2-64/packages/tar.spdx.json does not exist Update create-spdx-2.2.bbclass so that DEPLOY_DIR_SPDX includes ${SPDX_VERSION}, matching the expected deploy structure and restoring successful SPDX selftests. (From OE-Core rev: 8996d0899df5316742ba5fd73c351e8ca67dc90b) Signed-off-by: Kamel Bouhara (Schneider Electric) Signed-off-by: Steve Sakoman