Similar to what native and staging is doing since:
https://git.openembedded.org/openembedded-core/commit/meta/classes/native.bbclass?id=d6c7b9f4f0e61fa6546d3644e27abe3e96f597e2https://git.openembedded.org/openembedded-core/commit/meta/classes/staging.bbclass?id=1cf62882bbac543960e4815d117ffce0e53bda07
Cross task outputs can call native dependencies and even when cross
recipe output doesn't change it might produce different results when
the called native dependency is changed, e.g. clang-cross-${TARGET_ARCH}
contains symlink to clang binary from clang-native, but when clang-native
outhash is changed, clang-cross-${TARGET_ARCH} will still be considered
equivalent and target recipes aren't rebuilt with new clang binary, see
work around in https://github.com/kraj/meta-clang/pull/1140 to make target
recipes to depend directly not only on clang-cross-${TARGET_ARCH} but
clang-native as well.
I have added a small testcase in meta-selftest which demostrates this issue.
Not included in this change, but will send it if useful.
openembedded-core $ ls -1 meta-selftest/recipes-devtools/hashequiv-test/
print-datetime-link-cross.bb
print-datetime-link-native.bb
print-datetime-native.bb
print-datetime-usecross.bb
print-datetime-usenative.bb
print-datetime-native provides script which prints defined PRINT_DATETIME variable.
print-datetime-link-native and print-datetime-link-cross both provide a symlink to
the script from print-datetime-native.
print-datetime-usenative and print-datetime-usecross are target recipes using the
native and cross versions of print-datetime-link-* recipe.
# clean build all is rebuilt:
$ bitbake -k print-datetime-usenative print-datetime-usecross
WARNING: print-datetime-native-1.0-r0 do_install: print-datetime-native current DATETIME in script is 2025-11-13_20_05
WARNING: print-datetime-link-native-1.0-r0 do_install: print-datetime-link-native current DATETIME in symlink is 2025-11-13_20_05
WARNING: print-datetime-link-cross-x86_64-1.0-r0 do_install: print-datetime-link-cross-x86_64 current DATETIME in symlink is 2025-11-13_20_05
WARNING: print-datetime-usenative-1.0-r0 do_install: print-datetime-usenative current DATETIME from print-datetime-link is 2025-11-13_20_05
WARNING: print-datetime-usecross-1.0-r0 do_install: print-datetime-usecross current DATETIME from print-datetime-link is 2025-11-13_20_05
# keep sstate-cache and hashserv.db:
# print-datetime-usenative is correctly rebuilt, because print-datetime-link-native has different hash (because print-datetime-native hash changed)
# print-datetime-usecross wasn't rebuilt, because print-datetime-link-cross-x86_64 doesn't include the changed hash of print-datetime-native
$ bitbake -k print-datetime-usenative print-datetime-usecross
WARNING: print-datetime-native-1.0-r0 do_install: print-datetime-native current DATETIME in script is 2025-11-13_20_07
WARNING: print-datetime-link-native-1.0-r0 do_install: print-datetime-link-native current DATETIME in symlink is 2025-11-13_20_07
WARNING: print-datetime-link-cross-x86_64-1.0-r0 do_install: print-datetime-link-cross-x86_64 current DATETIME in symlink is 2025-11-13_20_07
WARNING: print-datetime-usenative-1.0-r0 do_install: print-datetime-usenative current DATETIME from print-datetime-link is 2025-11-13_20_07
It's because print-datetime-link-cross-x86_64 depsig doesn't include print-datetime-native signature:
$ cat tmp/work/x86_64-linux/print-datetime-link-cross-x86_64/1.0/temp/depsig.do_populate_sysroot
OEOuthashBasic
18
SSTATE_PKGSPEC=sstate:print-datetime-link-cross-x86_64:x86_64-oe-linux:1.0:r0:x86_64:14:
task=populate_sysroot
drwx .
drwx ./recipe-sysroot-native
drwx ./recipe-sysroot-native/sysroot-providers
-rw- 32 19fbeb373f781c2504453c1ca04dab018a7bc8388c87f4bbc59589df31523d07 ./recipe-sysroot-native/sysroot-providers/print-datetime-link-cross-x86_64
drwx ./recipe-sysroot-native/usr
drwx ./recipe-sysroot-native/usr/bin
drwx ./recipe-sysroot-native/usr/bin/x86_64-oe-linux
lrwx ./recipe-sysroot-native/usr/bin/x86_64-oe-linux/print-datetime-link -> ../print-datetime
While print-datetime-link-native doesn't have this issue, because print-datetime-native signature is there:
$ cat tmp/work/x86_64-linux/print-datetime-link-native/1.0/temp/depsig.do_populate_sysroot
OEOuthashBasic
18
print-datetime-native: 60f2734a63d708489570ca719413b4662f8368abc9f4760a279a0a5481e4a17b
quilt-native: 65d78a7a5b5cbbf0969798efe558ca28e7ef058f4232fcff266912d16f67a8b8
SSTATE_PKGSPEC=sstate:print-datetime-link-native:x86_64-linux:1.0:r0:x86_64:14:
task=populate_sysroot
drwx .
drwx ./recipe-sysroot-native
drwx ./recipe-sysroot-native/sysroot-providers
-rw- 26 3d5458be834b2d0e4c65466b9b877d6028ae2210a56399284a23144818666f10 ./recipe-sysroot-native/sysroot-providers/print-datetime-link-native
drwx ./recipe-sysroot-native/usr
drwx ./recipe-sysroot-native/usr/bin
lrwx ./recipe-sysroot-native/usr/bin/print-datetime-link -> print-datetime
With the cross.bbclass fix the link-cross recipe has a checksum from native recipe as well:
$ cat tmp/work/x86_64-linux/print-datetime-link-cross-x86_64/1.0/temp/depsig.do_populate_sysroot
OEOuthashBasic
18
print-datetime-native: 9ceb6c27342eae6b8da86c84685af38fb8927ccc19979aae75b8b1e444b11c5c
quilt-native: 65d78a7a5b5cbbf0969798efe558ca28e7ef058f4232fcff266912d16f67a8b8
SSTATE_PKGSPEC=sstate:print-datetime-link-cross-x86_64:x86_64-oe-linux:1.0:r0:x86_64:14:
task=populate_sysroot
drwx .
drwx ./recipe-sysroot-native
drwx ./recipe-sysroot-native/sysroot-providers
-rw- 32 19fbeb373f781c2504453c1ca04dab018a7bc8388c87f4bbc59589df31523d07 ./recipe-sysroot-native/sysroot-providers/print-datetime-link-cross-x86_64
drwx ./recipe-sysroot-native/usr
drwx ./recipe-sysroot-native/usr/bin
drwx ./recipe-sysroot-native/usr/bin/x86_64-oe-linux
lrwx ./recipe-sysroot-native/usr/bin/x86_64-oe-linux/print-datetime-link -> ../print-datetime
And print-datetime-usecross is correctly rebuilt whenever print-datetime-native output is different.
(From OE-Core rev: dccb7a185fe58a97f33e219b4db283ff4a2071d7)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The class called 'make menuconfig' without any of the make variables and
options set in EXTRA_OEMAKE, resulting in a quite different build
environment than actually intended.
For the kernel.bbclass this was fixed in commit 8c616bc0 ("kernel: Use
consistent make flags for menuconfig") by appending ${EXTRA_OEMAKE} to
KCONFIG_CONFIG_COMMAND.
Instead of fixing this individually for additional recipes, we simply
include ${EXTRA_OEMAKE} in KCONFIG_CONFIG_COMMAND by default.
For most class users, this change is directly visible in the generated
.config file:
* For barebox and u-boot, the CONFIG_GCC_VERSION erroneously reflected
the host GCC version before where it now correctly reflects the target
toolchain's GCC.
* For u-boot, also the "Compiler: " line at the beginning of the .config
now prints the target toolchain instead of the host ones.
* The kernel had this already set.
* busybox did not produce any difference.
Note that these projects might base some compile-time decisions on e.g.
the actual compiler version used. Having the wrong one in the
menuconfig-generated .config affects at least the visibility and
consistency.
Reported-by: Ulrich Ölmann <u.oelmann@pengutronix.de>
(From OE-Core rev: a7dd1c221e42fd8df1d6f1c76c6a5ab7a3e19542)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1b6ddd452837e67b500a84455a234f5edc8250a9)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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:<feature>
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 <JPEWhacker@gmail.com>
(From OE-Core rev: 5cfd0690f819379d9f97c86d2078c3e529efe385)
Signed-off-by: Kamel Bouhara (Schneider Electric) <kamel.bouhara@bootlin.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 7ec61ac40345a5c0ef1ce20513a4596989c91ef4)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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 <JPEWhacker@gmail.com>
(From OE-Core rev: 1fff29a0428778929ffa530482ebf7db95f1e0ae)
Signed-off-by: Kamel Bouhara (Schneider Electric) <kamel.bouhara@bootlin.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 228a968e7c47d811c06143279bdb0f9c5f374bef)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Per ruby maintenance policy [1], the 3.3.x branch should be still in normal
maintenance, so upgrade to the latest version 3.3.10 to fix many security
issues and bugs.
Remove the fix for CVE-2025-27219, CVE-2025-27220 and CVE-2025-27221 as
these fixes have been included in the new version.
[1] https://www.ruby-lang.org/en/downloads/branches/
(From OE-Core rev: bad372ad8ec33334c6a74c077bf975851c1e59d2)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Fix an out-of-bounds read triggered by a malicious rsync client
acting as a receiver. The issue can be exploited with read access
to an rsync module.
CVE: CVE-2025-10158
(From OE-Core rev: 110933506d7a1177d1a074866d08fe0b0da612d7)
Signed-off-by: Adarsh Jagadish Kamini <adarsh.jagadish.kamini@est.tech>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This reverts commit e6de433ccb2784581d6c775cce97f414ef9334b1.
This introduced a breaking change which is not suitable for backport to
stable LTS branches.
(From OE-Core rev: 2b3d2b671a149cbeea2bdc9ba42192da2015c3b7)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Introduce new packageconfig to explicitly avoid compilation of
experimental code. Note that the code was not compiled by default also
before this patch, this now makes it explicit and makes it possible to
check for the flags in cve-check code.
This is less intrusive change than a patch removing the code which was
rejected in patch review.
This will solve CVE-2025-59777 and CVE-2025-62689 as the vulnerable code
is not compiled by default.
Set appropriate CVE status for these CVEs based on new packageconfig.
(From OE-Core rev: 9e3c0ae261afb7b9ff9528dbc147fb6c89d5a624)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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) <kamel.bouhara@bootlin.com>
CC: JPEWhacker@gmail.com
(From OE-Core rev: 04cc49593a0ba2c51e4f4d477d4587079735b624)
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Due to what looks like a copy'n'paste mistake, the environment setup script
might override 'CURL_CA_BUNDLE' from the host env instead of leaving it
untouched. Fix that.
(cherry picked from commit 545e43a7a45be02fda8fc3af69faa20e889f58c4)
CC: changqing.li@windriver.com
CC: raj.khem@gmail.com
CC: Peter.Marko@siemens.com
(From OE-Core rev: ef198b0c6063ede32cb93fe44eb89937c076a073)
Signed-off-by: Moritz Haase <Moritz.Haase@bmw.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Pick commit per NVD report.
Add two patches to apply it cleanly.
(From OE-Core rev: 4e03bed20bceb455cb46dcf9564ad5a8525b207d)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Pick commit per NVD report.
(From OE-Core rev: e8fbb7521e0113c467e07ba473a46612709c5311)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Pick commit per NVD report.
(From OE-Core rev: f3bdbd782eed2b597927df489a7d38a22fbba5ed)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Pick commit per NVD report.
Add two patches to apply it cleanly.
(From OE-Core rev: 285a495b8b0e8fa93a0a0884f466f1adca76a28a)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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 <peter.marko@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit ee6541d0940c65685aaafd7d41a59a9406392e7d)
Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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 <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit ead9c6a8770463c21210a57cc5320f44f7754dd3)
Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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 <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 45e18f4270d084d81c21b1e5a4a601ce975d8a77)
Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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 <marta.rybczynska@syslinbit.com>
Signed-off-by: Samantha Jalabert <samantha.jalabert@syslinbit.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 6352ad93a72e67d6dfa82e870222518a97c426fa)
Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
In scarthgap, the `oe.cve_check.get_patched_cves()` method only returns
CVEs with a "Patched" status. We want to retrieve all annotations,
including those with an "Ignored" status. Therefore, to avoid modifying
the current API, we integrate the logic for retrieving all CVE_STATUS
values directly into `spdx30_task`.
(From OE-Core rev: 9a204670b1c0daedf1ed8ff944f8e5443b39c8f7)
Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This reverts part of commit 4859cdf97fd9a260036e148e25f0b78eb393df1e.
Modification of meta/classes/create-spdx-2.2.bbclass is not backported,
so no need to consider it.
In the commit, it updates spdx according to bitbake change. But the
bitbake commit
* 2515fbd10 fetch: Drop multiple branch/revision support for single git urls
doesn't backport for scarthgap.
So revert the other parts of the commit 4859cdf97fd9a260036e148e25f0b.
(From OE-Core rev: f3bfb98d1cf928678d9931308c116e9e6ec64ba5)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Currently meson inside eSDKs only works with fully populated eSDKs,
but our testing uses minimal eSDKS, so skip the test if the eSDK is a
minimal build. A bug has been filed to resolve this.
This is minimal change extracted from OE-Core commit which has this only
as a minor comment: 575e0bf52db0467d88af4b5fe467b682f10ca62a
(From OE-Core rev: 7cfacaee1b3319e561036512a849e762d0f68a5e)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
