Re: [Buildroot] [RFC PATCH 0/5] Support SBOM in CycloneDX format

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

Hello,

On Wed, 10 Apr 2024 21:26:09 +0200
Arnout Vandecappelle <arnout@mind.be> wrote:

> > An SBOM is totally worthless when generated on the developers machines,
> > as the build environment there is uncontrollable; it is useless during
> > development as well [0]. An SBOM only ever makes sense when generated in
> > a delivery pipeline, like in a CI/CD pipeline.  
> 
>   Huh? It's equally worthless as the images created by Buildroot then. Those are 
> also uncontrollable. Of course, you have no guarantee that the SBoM corresponds 
> to the image that gets shipped to customers, but that's not really relevant. You 
> can still use the SBoM to see which packages get installed, which patches are 
> applied, which CVEs apply, which licenses are used, etc.

Yes, I agree the argument from Yann here is a bit dubious, but do we
care?

>   And anyway, I don't think it's very relevant if this SBoM generation happens 
> on a developer machine or in CI. In either case, I don't think we want to rely 
> on a host-installed Python version.

Why?

> > We should now drop printvars.  
> 
>   OMG, I completely forgot about show-vars! But indeed, we still need to keep 
> show-vars. And we should drop printvars.

We don't care about backward compatibility?

> > Another example, is that (AFAICS) there is no dedicated way to describe
> > reverse depdndencies in cylonedx, except by injected an arbitrary
> > property, which means that it does not really fit... show-info provides
> > that.  
> 
>   True.

So, how do you propose that CycloneDX replaces show-info, if CycloneDX
cannot represent all information that is emitted today in show-info?

> > More generally: there is information that belongs to show-info, as it is
> > usefull for generating various reports, that have absolutely no meaning
> > in an SBOM,  
> 
>   What kind of information would that be? show-info and an SBoM are pretty much 
> the same thing: a list of packages and their properties.

Well, see above?

> > and so there is no reason to inject those in cyclonedx just
> > because something else may need it. That's what show-info is for  
>   Anyway, for me replacing show-info is not the most important thing, it's more 
> a nice-to-have. What I don't want is to generate CycloneDX by post-processing 
> the show-info output, because it turns out that that is still fairly complicated 
> and it's just easier to directly generate CycloneDX from make.

Why is it "fairly complicated"? It sounds to me that post-processing
show-info into a simple and nice Python script to generate CycloneDX is
not at all "fairly complicated" but rather "fairly simpler" than doing
it in make.

Even from a pure architecture point of view, it makes a lot of sense to
have a Buildroot-specific show-info emitted a JSON blurb with as much
information as we want (we don't need to comply with any standard), and
*then* have post-processing tool consume this Buildroot-specific JSON
blurb and turn it into CycloneDX, SPDX, whatever people want, by using
the relevant information provided in the Buildroot-specific JSON blurb.

So I'm sorry, but your argumentation is not convincing at all :-/

> > And as Thomas said, if show-info is missing data, we can easily add it.
> >   
> >> - For legal-info, it's quite obvious that cyclonedx should basically replace
> >> that - though legal-info currently still does a number of additional steps
> >> (e.g. collect the actual source) that cyclonedx doesn't cover. I also think
> >> the manifest.csv file makes a lot of sense. I'm not sure how to solve that,
> >> but I can imagine that there could still be an explicit legal-info target
> >> that consumes the cyclonedx file and does some additional steps.  
> > 
> > Or the other way around: cyclonedx consumes the output of legal-info.  
> 
>   Again, it's going to be much easier to generate everything from make rather 
> than post-processing the output of legal-info and show-info.

Do you have some real argument to back this affirmation? Python code
is typically much more readable than make code, and it's easier to do
text manipulation in Python than in make.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot