On 2/11/22 09:00, Mikko Rapeli wrote: > 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 :) >
I want to add file checksums to that wishlist. Jacob
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161636): https://lists.openembedded.org/g/openembedded-core/message/161636 Mute This Topic: https://lists.openembedded.org/mt/89018266/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
