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 12:28:06PM +0300, Mikko Rapeli via lists.openembedded.org wrote:
> Hi,
>

Hi Mikko,

> On Wed, Jul 16, 2025 at 11:05:17AM +0200, Kamel Bouhara via 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.

> If some information is in the build system, then developers can read it from there
> also when doing reviews and audits. For kernel, the -dev binary package has the
> effective config after build has completed.
>

I believe, SPDX provides a more structured, standardized, and portable format that makes
it easy to expose and reuse this data in CI pipelines, and when publishing SBOMs
externally. It becomes a central source that avoids custom parsing or packaging
assumptions and integrates well with tooling for compliance, vulnerability tracking
and auditing.

Thanks again for the feedback.

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