Re: [OE-core] [PATCH wrynose 0/4] spdx: fix the compiled-sources filter

[Benjamin Robin <benjamin.robin@bootlin.com>]

On Saturday, September 26, 2026 at 11:19 AM, Yoann Congal wrote:
> 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.

Hello Yoann,

> Can we do the fix without this change?

Technically, we could do it. But it wouldn't be exactly the same series,
which I don't really like, and the code will diverge.
For information I could develop a solution after ELCE capable of
generating a similar SBOM if Kazuyoshi doesn't feel comfortable doing it.


-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com