On Friday, February 6, 2026 at 4:50 PM, Joshua Watt wrote: > > But on my side, I first tried a normal build with an empty build > > directory. > > The build failed around SPDX generation. For information I used the > > following KAS configuration:
I should have specified that when building a minimal image with your branch, I have the following error: ERROR: opkg-utils-native-0.7.0-r0 do_create_recipe_sbom: Could not find a recipes SPDX document named recipe-opkg-utils-native ERROR: Logfile of failure stored in: /work/build/tmp/work/x86_64-linux/opkg- utils-native/0.7.0/temp/log.do_create_recipe_sbom.113690 ERROR: Task (virtual:native:/work/build/../layers/openembedded-core/meta/ recipes-devtools/opkg-utils/opkg-utils_0.7.0.bb:do_create_recipe_sbom) failed with exit code '1' I am not able to build an image using your branch. > > ------------------- > > > > header: > > version: 18 > > > > build_system: openembedded > > machine: qemuarm > > distro: poky > > target: core-image-minimal > > > > repos: > > bitbake: > > url: https://git.openembedded.org/bitbake > > commit: af9dd012e7f4d16dccd1d6118be5da94ede68f85 > > branch: master > > path: layers/bitbake > > > > layers: > > .: disabled > > > > openembedded-core: > > url: https://git.openembedded.org/openembedded-core-contrib > > #commit: 6ce19709f7835ee5cd7915e181f89397975236c8 > > commit: 43737d14ab039c507a1a71177da68c7b41e4622f > > branch: jpew/recipe-sbom > > path: layers/openembedded-core > > > > layers: > > meta: > > meta-yocto: > > url: https://git.yoctoproject.org/meta-yocto > > commit: de4abc0a175af12eacc761a2e1e60ca7fdfeaa1b > > branch: master > > path: layers/meta-yocto > > > > layers: > > meta-poky: > > meta-openembedded: > > url: https://git.openembedded.org/meta-openembedded > > commit: 3787ecadbb198f56ac43025a15b3339c810c3a66 > > branch: master-next > > path: layers/meta-openembedded > > > > layers: > > meta-oe: > > meta-python: > > > > meta-networking: > > meta-sbom-cve-check: > > url: https://github.com/bootlin/meta-sbom-cve-check.git > > commit: ea9fecee6073abab0f8d5d7ccb02077d1c6dc504 > > branch: main > > path: layers/meta-sbom-cve-check > > > > local_conf_header: > > cleanup: | > > > > INHERIT += "rm_work" > > > > spdx: | > > > > INHERIT += "vex" > > > > ------------------- > Ya, this is because I tried to "reuse" the recipe deploy directory for > do_create_recipe_spdx; I can fix this. Thanks. > > Unless I'm mistaken, this information is not provided in the SBOM that can > > be found in the deploy directory. > > > > The following command does not return anything: > > > > python3 -m json.tool build/tmp/deploy/images/qemuarm/core-image-minimal- > > qemuarm.rootfs.spdx.json | grep -E "is.native" > > > > Same result with meta-world-recipe-sbom-recipe-sbom.spdx.json > > Yes, sorry. My statement was not clear; you won't find any native > markers in the SBoM output today, but we have mechanisms in place to > do that, so it should be pretty easy and I can work on it. Oh, OK. I was confused because, when I was looking at the code, this was indeed not implemented. > > I currently use the `build_Build` in sbom-cve-check. The goal is to speed > > up CVE analysis, since a recipe should only provide "one" CPE (there can > > be multiple CPEs, but they all identify the same "component") and one > > version. > > > > From the `build_Build` object, the packages are grouped (if they share the > > same > > CPEs and version), and the analysis is done on this group. This is > > especially important for the kernel and associated modules. We could have > > hundreds of kernel packages sharing the same CPE. > > > > I noticed that the `build_Build` object is no longer used when generating > > meta-world-recipe-sbom-recipe-sbom.spdx.json. sbom-cve-check currently > > cannot handle that, but I could change the way it works, will see. We > > really need to discuss that. > > Right, it kinda depends on your use case. There are basically two of > them right now: > 1) Running CVE analysis on all recipes to determine if any _recipes_ > have new CVEs that need to be triaged. This should be doable without > actually having to build the recipes, since that would take a long > time. This is the more "proactive" CVE maintenance that upstream and > many companies want to do. > 2) Running CVE analysis on a specific product SBoM to determine if > there are any CVEs that affect that product. Your tool currently > handles this really well. > > I've not looked too closely at the code for your tool, but I'm hoping > that it wouldn't be too difficult to handle either use case. I'm kinda > thinking the tool should be able to handle either, since the SBoM for > #2 is just a superset of #1. If there is something that we need to do > to the SBoM to clearly distinguish the difference between them so your > tool can do the right thing, let me know. Yes, if I understood correctly, #2 will be a superset of #1. But sbom-cve- check relies (for now) on build_Build which is included in #2 (but not in #1). So this is not going to work for #1. sbom-cve-check heavily relies on the concept of a build (recipe), which provides: sources and packages. Since I am not able to generate a "normal" SBOM file associated with a built image, I can check what would be the format of this SBOM after the changes that you have made. > Waiting on this seems best. It's not clear what the best long-term > solution is going to be right now, and I wouldn't want to spend time > developing a solution that was a dead end. Yes, I agree. -- Benjamin Robin, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#230629): https://lists.openembedded.org/g/openembedded-core/message/230629 Mute This Topic: https://lists.openembedded.org/mt/117638558/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
