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. 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.
-----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 https://urldefense.com/v3/__https://bootlin.com__;!!KEiQlu1B30Bt!3IKXBRtAGpk1LcoaKtP_q1pM91WPOIIVa-2qIAJhzvnrSCmUbNDoWnu6RU-TaPNhiDq0ol8mRpUivxOLMiHHZ6clSr7ziv8FvOs$
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#246744): https://lists.openembedded.org/g/openembedded-core/message/246744 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]] -=-=-=-=-=-=-=-=-=-=-=-
