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 <[email protected]> >> Sent: Monday, September 28, 2026 5:57 PM >> To: KAZUYOSHI AKIYAMA (秋山 和慶) <[email protected]>; >> [email protected]; Yoann Congal >> <[email protected]> >> Cc: Richard Purdie <[email protected]>; Mathieu >> Dubois-Briand <[email protected]> >> 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#246978): https://lists.openembedded.org/g/openembedded-core/message/246978 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]] -=-=-=-=-=-=-=-=-=-=-=-
