Re: [OE-core] [PATCH 1/1] spdx3: Add optional kernel configuration export to build_parameter for virtual/kernel

[Kamel Bouhara <kamel.bouhara@bootlin.com>]

On Wed, Jul 16, 2025 at 09:30:11AM -0400, Bruce Ashfield via lists.openembedded.org wrote:
>    On Wed, Jul 16, 2025 at 7:34 AM Kamel Bouhara via
>    [1]lists.openembedded.org
>    <kamel.bouhara=[2]bootlin.com@lists.openembedded.org> wrote:
>
>      On Wed, Jul 16, 2025 at 12:28:06PM +0300, Mikko Rapeli via
>      [3]lists.openembedded.org wrote:
>      > Hi,
>      >
>      Hi Mikko,
>      > On Wed, Jul 16, 2025 at 11:05:17AM +0200, Kamel Bouhara via
>      [4]lists.openembedded.org wrote:
>      > > Enhances SPDX Document by extracting kernel build-time
>      configuration settings from '${B}/.config'.
>      > >
>      > > Each CONFIG_* line is parsed and exported as a DictionaryEntry
>      in the build_Build.build_parameter
>      > > section of the SPDX document. This provides better visibility
>      into kernel build behavior and
>      > > configuration, in alignment with the SPDX3 metadata model.
>      > >
>      > > The feature is gated by a new tunable variable:
>      > >
>      > >     SPDX_INCLUDE_KERNEL_CONFIG (default: "1")
>      > >
>      > > Setting this to "0" disables exporting the kernel configuration,
>      which may be useful to improve
>      > > performance or reduce the size of generated SPDX documents.
>      > >
>      > > Example:
>      > >
>      > >     CONFIG_FOO=y  →  { key: "CONFIG_FOO", value: "y" }
>      > >
>      > > This complements existing metadata export features and enables a
>      more complete audit trail of how
>      > > the kernel is built within a given build.
>      >
>      > Why is the kernel so special? All other SW components have build
>      time configs too.
>      >
>      > For information harvesting, a lot of data can be extracted from
>      the build system
>      > but to me it's important that the build system and tools benefit
>      the users
>      > who actually do maintenance and development work. They need to be
>      able to see
>      > what patches get applied, what they fix, what configs are used
>      etc. Extracting
>      > all possible info into some IT management tooling which never
>      directly feeds
>      > back to the build system or developers to actually improve the CVE
>      patch status,
>      > enable security features and updates and fixes for real bugs, is
>      not very useful.
>      >
>      You're absolutely right to question the special handling of the
>      kernel.
>      In this case, the choice was intentional: the kernel’s .config is
>      well-structured,
>      easy to locate, and critical to the system's security and behavior.
>      It's also a central component of the BSP, making it a strong
>      candidate for initial
>      integration when experimenting with build-time metadata capture in
>      SPDX.
>      That said, I fully agree, many other software components also have
>      meaningful
>      build-time configuration (e.g., PACKAGECONFIG, EXTRA_OECONF, cmake
>      flags), and the
>      longer-term goal is to extend support to those as well.
>      Starting with the kernel gives us a good foundation to validate the
>      approach.
>      Importantly, the patch makes this metadata inclusion optional and
>      configurable.
>      It introduces a variable to let users control the granularity of
>      what gets
>      included in the SPDX document. That means teams can choose to
>      include or exclude
>      details like kernel configuration based on their policy, use case,
>      or audit needs.
>      About usefulness to developers, I agree this info only brings value
>      if it
>      integrates back into yocto developers workflows. That’s exactly the
>      direction
>      I’m aiming for, for example, we’ve added support in our SBOM diff
>      tool to compare
>      kernel configuration between builds by parsing CONFIG_* entries.
>      This mostly lets teams audit config changes over time and detect if
>      a
>      some security-hardening option was unintentionally disabled.
>

>    I have the same concerns and opinion on this as Mikko
>    As long as this doesn't add overhead, or becomes mandatory, my
>    objections can
>    be ignored.
>    But generally speaking, I'm opposed to jamming everything into SPDX and
>    using
>    it as a tool for what you are describing above. There are already
>    existing tools that
>    are focused and better at comparing configurations of packages (and the
>    kernel).
>    Turning SPDX into some kind of one-stop-shop and everything-in-one
>    place tool
>    is something I'd object strongly to.  (I do realize you are talking
>    about using some
>    sort of other tool reading the SPDX data, but my objection is just the
>    same if it
>    becomes an absolutely massive monolithic data source).
>    Bruce
>

Hi Bruce,

Thanks for the feedback.

Just to clarify, the goal here isn't to turn SPDX into a one-stop-shop or to
overload it with every piece of build metadata. The intent is to capture a minimal
and focused subset of build-time parameters
(like kernel .config, PACKAGECONFIG, etc.) where:

    - The structure is already well-defined
    - The data is relevant for security or compliance
    - And the cost of extraction is very low

This is fully gated behind an opt-in variable (and could default to disabled).
The idea is not to replace existing tools but rather to provide a structured,
portable format for key metadata, especially in SBOM-driven environments where SPDX
is already part of the process.

In my use case, this metadata is consumed by a targeted diff tool; not treating
SPDX as the end-goal, but more like a transport format. This approach lets us
reuse existing SPDX outputs without interfering with or duplicating the role of
more purpose-built tools.

So I hear you: this shouldn't become bloated, mandatory. The goal is simply to make
sure when people do need to trace how something was built, especially in CI or
audit contexts, they have a consistent hook, and it can be disabled entirely if
not useful.

Cheers,

--
Kamel Bouhara, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com