On Thursday, 10 February 2022 04:34:16 NZDT Richard Purdie wrote: > On Wed, 2022-02-09 at 14:27 +0000, [email protected] wrote: > > On Wed, Feb 09, 2022 at 01:40:22PM +0000, Richard Purdie wrote: > > > On Wed, 2022-02-09 at 13:27 +0000, [email protected] wrote: > > > > Hi, > > > > > > > > On Wed, Feb 09, 2022 at 12:23:39PM +0000, Richard Purdie wrote: > > > > > People have requested changes like this before and I rejected it as > > > > > I'm worried that allowing people to customise this code will just > > > > > fork the project into many different directions. > > > > > > > > It's the other way round. There are a lot of needs to extract metadata > > > > from > > > > build system into something where reports can be generated. > > > > > > I don't doubt that however buildhistory was written for a specific > > > purpose and if we start adding the ability to customise it heavily we > > > lose the ability for comparisions to be made, or sstate reuse and so > > > on. > > > > > > I'm partly channelling the original author's views on this since they > > > had some very specific thoughts on this change. I do sometimes wonder > > > if I should continue doing that though :/. > > > > Then how should yocto users export CVE_NAME, LICENSE, PN, PV, SRC_URI etc > > from the build system to generate SW bill of materials (BOM) for their > > product and track progress? > > > > Yes, SPDX can be the other answer but I don't find that human readable or > > working out of the box atm. > > buildhistory was not intended for SBOM generation, that is what create-spdx > is being developed for. They have two quite different intentions and trying > to turn one into the other is why I have concerns about this patch. > > For example, of we did go this way, next, we may need to either write a > converter of buildhistory to SPDX format, or change buildhistory to use SPDX > format so that it has a standard SBOM output form. This is not the > direction we want/need to go.
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. 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. Cheers Paul [1] based upon the earlier testlab and packagehistory classes that were written by others
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161633): https://lists.openembedded.org/g/openembedded-core/message/161633 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]] -=-=-=-=-=-=-=-=-=-=-=-
