Re: [OE-core] [poky][master][PATCHv2] buildhistory.bbclass: Enable exporting more recipe and package data

[Paul Eggleton <bluelightning@bluelightning.org>]

On Thursday, 10 February 2022 04:34:16 NZDT Richard Purdie wrote:
> On Wed, 2022-02-09 at 14:27 +0000, Mikko.Rapeli@bmw.de wrote:
> > On Wed, Feb 09, 2022 at 01:40:22PM +0000, Richard Purdie wrote:
> > > On Wed, 2022-02-09 at 13:27 +0000, Mikko.Rapeli@bmw.de 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