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

[Quentin Schulz via buildroot <buildroot@buildroot.org>]

Hi Thomas,

On 4/9/26 10:43 PM, Thomas Perale wrote:
> Adding Arnout to the discussion, we briefly discussed this during the 
> FOSDEM Dev Meeting. Maybe he can share his point of view as well.
> 
> On 4/9/26 10:42 PM, Thomas Perale wrote:
>> 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 ?
>>

Nope, but I think it could be important (though not sure 
generate-cyclonedx have a way to know whether you're building an image 
or an sdk, or even if it should). FWIW, we strip our SBOM of the host 
packages. We weren't asked for an SBOM but for versions of the software 
running on our products, so a strictly valid SBOM isn't required per-se 
for now. That may change though. (we also duplicate components for which 
we know there are multiple CPEs, since CycloneDX has decided to not 
support that and there are multiple instances of packages having 
multiple CPEs (arm-trusted-firmware, optee-os to name only those).

>>> 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:// 
>> eur02.safelinks.protection.outlook.com/? 
>> url=https%3A%2F%2Fgithub.com%2FCycloneDX%2Fspecification%2Fdiscussions%2F712&data=05%7C02%7Cquentin.schulz%40cherry.de%7C571d171992b84ec86a4208de9678ad6c%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C639113642214259479%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gl4Nx2Id9MjfJ4DfXvVVlmfhhG5xxqVkhAqnGzrCcL4%3D&reserved=0
>>
>> 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.
>>

I don't understand deployment environment as being Buildroot. I 
understand it as being the device where this runs (hardware, OS, shared 
libraries and external binaries linked against/called at runtime). So 
the target device is the deployment environment. Deployment environment 
is where it's deployed, not where it's built. When I say "I'm deploying 
to production", nobody cares from which PC I do this, but to which 
device/server I'm deploying.

>> 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 ?
>>

This sounds like a better match for a Buildroot host package. Though the 
comment you referred to uses both .isExternal=True and .scope=excluded 
as example. The question is where to draw the line... As far as I 
remember, some host tools are not built by Buildroot, Buildroot expects 
them to be available on the host system. So, should the host system be 
part of the SBOM too? (Of course, that's likely outside of Buildroot's 
scope for generating an SBOM).

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

Maybe we should start a Discussion on GitHub about that? Yocto doesn't 
have official support for CycloneDX (only SPDX) so not much we can check 
on that side.

Cheers,
Quentin
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot