Re: [Buildroot] [PATCH v5 6/8] utils/generate-cyclonedx: mark host packages as external

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

Hi Quentin,

In reply of:
> Hi Thomas,
> 
> On 3/11/26 3:04 PM, Thomas Perale via buildroot wrote:
> > Mark Buildroot's host packages as 'external' with the 'isExternal'
> > property. Starting CycloneDX v1.7 [1][2] the CycloneDX spec defines this
> > property like the following [3].
> > >> An external component is one that is not part of an assembly, but is
> >> expected to be provided by the environment, regardless of the
> >> component's .scope. This setting can be useful for distinguishing which
> >> components are bundled with the product and which can be relied upon to
> >> be present in the deployment environment.
> > > This fits the usage of 'host' packages : a package provided by the
> > environment and not bundled with the target.
> > 
> That's not my understanding. None of the examples provided in the GitHub issue match a requirement on host executables (in the context of cross-compilation).

Couldn't find any example that would suit the Buildroot case as well.

> They all are related to runtime dependencies (dynamic linking, interpreters, hardware-limitation (which SoC/CPU can this run on)) you need to use with the binary(ies) associated with that SBOM.
> What Buildroot generates is likely self-sufficient?

As you said, I think this property was mostly added to support dynamicly linked libraries. 

> A Buildroot SDK is kinda different, but then the host packages wouldn't be external anyway since they would be part of the SDK and thus "internal".

If you need to create an SBOM of the Buildroot SDK itself indeed that would be
a completely different "point of view" for the software and would require a
different logic. 

Is it something you are trying to create ?

> Do you have a different reading of the spec on this? (We just started to look at CycloneDX generated by Buildroot so I wouldn't trust my own gut-feeling on that :) ).

As you said, I don't think they have taken into account the use-cases for
build-systems. It's mostly an interpretation of the spec that made me add this
property.

I saw other implementation use the `scope: excluded` property but imo it make
less sense.

According to this discussion: https://github.com/CycloneDX/specification/discussions/712

For `isExternal` they mention: 

> This setting can be useful for distinguishing which components are bundled
> with the product and which can be relied upon to be present in the deployment
> environment

If the firmware you generate with Buildroot is the "bundled product" and the
build-system the "deployment environment" I found this property to suit well
our use-case.

For the `scope` property they mention:

> "excluded" - Components that are excluded provide the ability to document
> component usage for test and other non-runtime purposes. Excluded components
> are not reachable within a call graph at runtime.

The "other non-runtime purposes" part could also suits the "host" package
definition I guess ?

It's all interpretation so it's good that we have these discussions :-)

PERALE Thomas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot