Hi, On Fri, Feb 11, 2022 at 04:49:21PM +1300, Paul Eggleton wrote: > FWIW I'll just chime in here as the original author[1] and say I agree with > Richard. If folks are needing an alternative SBOM generation mechanism to > SPDX, or have other use cases for extracting build information, then I'd > prefer we take a step back and design such a thing properly. The original > idea > was (1) to expose changes in the output that might not readily apparent > otherwise, and (2) expose selected "input" values that would (or could) > materially influence the output, so you hopefully have a ready explanation > for > why an image / package increased in size or dependencies got added etc.
First of all, thanks for buildhistory, Paul! > I will accept that over time buildhistory has added things here and there > that > further the idea of using it for SBOM, folks no doubt have been using these > for such purposes, and I'm not 100% opposed to making small additions where > they make sense. However, even with this proposed extension, buildhistory is > still not capable of recording sufficient information that (I believe) is > expected in a modern SBOM - for example, the list of patches applied / CVEs > resolved as a result - and I don't think it would be wise to extend it to do > so. We certainly don't want to give folks the idea that buildhistory is good > enough to resolve their SBOM requirements when we haven't designed it to do > so, particularly as for many folks there are legal and regulatory concerns > involved. Maybe I'm "abusing" buildhistory then. The way it enables to have a git repo view with full history of releases on metadata available in SW builds is really invaluable. We seem to be abusing it to export various bitbake recipe variables from product configuration so that we can later on do some QA checks on them and record the details in nice git history view. There could be other ways to implement the same use cases. We could have real QA checks in the bitbake builds which make sure certain recipe variables are correctly filled. We could export them into image manifest files or even SDPX to record the details per release. Then we could manually diff the files between releases to check for delta. Or a custom data format, maybe in json. Yocto CVE checker uses a custom text format, a bit similar to buildhistory as output. There is the json patch from Microsoft in review. Currently I don't see SPDX output replacing buildhistory and CVE checker output completely. Then there is the current discussion about ABI dumps and how to store and export them and buildhistory was at least initially mentioned there. Gah, now I thought about saving SPDX, CVE checker and ABI dump output in buildhistory too. Would actually be nice. Sorry, yet another use case where easy access build metadata to compare over time and releases would be really handy. This never ends. You've created a monster :) -Mikko
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161635): https://lists.openembedded.org/g/openembedded-core/message/161635 Mute This Topic: https://lists.openembedded.org/mt/89018266/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
