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

["Yoann Congal" <yoann.congal@smile.fr>]

Hello,

@Joshua (and other SPDX/SBOM interested parties):
As our "SPDX/SBOM guy", I would love to have your input on this thread.
FYI, We (Paul or I) plan to raise this at the next tech call.

>> -----Original Message-----
>> From: Benjamin Robin <benjamin.robin@bootlin.com> 
>> Sent: Monday, September 28, 2026 5:57 PM
>> To: KAZUYOSHI AKIYAMA (秋山 和慶) <kazuyoshi_akiyama@jp.honda>; openembedded-core@lists.openembedded.org; Yoann Congal <yoann.congal@smile.fr>
>> Cc: Richard Purdie <richard.purdie@linuxfoundation.org>; Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
>> Subject: Re: [OE-core] [PATCH wrynose 0/4] spdx: fix the compiled-sources filter
>>
>> 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

On Mon Sep 28, 2026 at 11:39 AM CEST, KAZUYOSHI AKIYAMA (秋山 和慶) wrote:
> Thank you for your comments, Yoann and Benjamin.
>
> I agree with Benjamin.
> This series does introduce a visible change that the source path in
> SPDX will be changed from `sources/XXX/YYY.c` to `XXX/YYY.c`.
> However, the design change of the patch 0002 is reasonable, and I
> believe it is better to avoid code divergence whenever possible.
> The impact of this change is very small.
Do you have anything to support this affirmation?
I can imagine users having quite strict processes around SBOMs that
could be disrupted by a change like this (e.g. diff'ing SBOMs across
versions).

> I could write a patch to preserve the `sources/` prefix, but even
> then, wrynose users would still need to adapt to this change in the
> next LTS release.
> Furthermore, if I write such a patch, the path change would occur
> silently in the next LTS release, without sufficient context to
> document it properly in the release notes.
Breaking changes like this when changing release is expected and not a
problem at all.

Regards,
-- 
Yoann Congal
Smile ECS