On Thu Sep 17, 2026 at 6:24 AM CEST, KAZUYOSHI AKIYAMA via
lists.openembedded.org wrote:
> SPDX_INCLUDE_COMPILED_SOURCES is meant to filter all source files down to
> only the ones that were compiled before adding them to the SBOM,
> but on wrynose it doesn't work.
> add_package_files() is what picks which files go into the SBOM.
> It walks ${SPDXWORK} itself to get file paths,
> then keeps only the ones that match the list of compiled sources
> returned by get_compiled_sources().
> get_compiled_sources() just returns what save_debugsources_info() stored,
> and that data uses paths rooted at ${TARGET_DBGSRC_DIR}
> (= /usr/src/debug/${PN}/${PV}), not the ${SPDXWORK}-rooted paths
> add_package_files() compares against.
> So the list get_compiled_sources() returns never matches
> what add_package_files() is comparing,
> and almost every file ends up marked as not compiled.
> This happens for every recipe except the kernel,
> which has its own special-cased path.
>
> This isn't just a matter of the SBOM missing the right files.
> sbom-cve-check uses the same match result to decide whether
> a vulnerable file was actually built, for its vulnerability triage.
> If the match count is always zero, that triage doesn't work either.
> On yocto-6.0.2 we confirmed the misjudgment affects cpio and perl.
>
> master already has this fixed,
> and this backport brings that fix to wrynose.
> b567c2f0d9 is the commit that fixes it.
> Everything else in the series is a prerequisite for that patch.
> Backporting b567c2f0d9 along with its prerequisites
> brings wrynose's behavior in line with master.
> With this, compiled sources get counted correctly,
> and sbom-cve-check's triage works correctly too.
>
> On wrynose (genericx86-64, core-image-full-cmdline),
> the match rate goes from effectively zero to 93.9%.
>
> One thing changes.
> What the SBOM records as a source file name changes too.
> aa44a0f0eb re-unpacks under UNPACKDIR instead of WORKDIR,
> so a recorded source file name changes
> (e.g. sources/acl-2.3.2/... becomes acl-2.3.2/...).
> This is a change to SBOM metadata only.
> The actual build output is unaffected.
> Anyone diffing SBOMs across LTS point releases will see it.
Hello,
Thanks for the series, this sounds like a worthy fix.
But, this SBOM change is a bit more intrusive than I'm confortable
with... This will create a lot of noise for users that precisely track
their SBOMs.
Can we do the fix without this change?
Thanks!
--
Yoann Congal
Smile ECS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#246633):
https://lists.openembedded.org/g/openembedded-core/message/246633
Mute This Topic: https://lists.openembedded.org/mt/121291546/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
