From: "Antonin Godard" <antonin.godard@bootlin.com>
To: <stondo@gmail.com>, <docs@lists.yoctoproject.org>
Cc: <Peter.Marko@siemens.com>, <adrian.freihofer@siemens.com>,
<jpewhacker@gmail.com>, <stefano.tondo.ext@siemens.com>
Subject: Re: [docs][PATCH] ref-manual/dev-manual: document new SPDX variables and capabilities
Date: Thu, 19 Mar 2026 09:47:47 +0100 [thread overview]
Message-ID: <DH6MMYTW9EGG.1Y32J8PZPX2T8@bootlin.com> (raw)
In-Reply-To: <20260317085735.32664-1-stondo@gmail.com>
Hi,
On Tue Mar 17, 2026 at 9:57 AM CET, Stefano Tondo via lists.yoctoproject.org wrote:
> From: Stefano Tondo <stefano.tondo.ext@siemens.com>
>
> Document the new variables and features introduced by the SPDX
> enrichment patch series merged in OE-Core:
>
> New variables in ref-manual/variables.rst:
> - SPDX_FILE_EXCLUDE_PATTERNS: regex-based file exclusion from SBOM
> - SPDX_IMAGE_SUPPLIER: supplier agent for image SBOMs
> - SPDX_SDK_SUPPLIER: supplier agent for SDK SBOMs
> - SPDX_PACKAGE_SUPPLIER: supplier agent for individual packages
> - SPDX_INVOKED_BY: agent that invoked the build
> - SPDX_ON_BEHALF_OF: agent on whose behalf the build runs
>
> Updated dev-manual/sbom.rst:
> - Add bullet points for file exclusion patterns, supplier
> information, and ecosystem-specific PURL enrichment via
> bbclasses (cargo_common, go-mod, pypi, npm, cpan)
>
> Signed-off-by: Stefano Tondo <stefano.tondo.ext@siemens.com>
> ---
> documentation/dev-manual/sbom.rst | 13 +++++
> documentation/ref-manual/variables.rst | 78 ++++++++++++++++++++++++++
> 2 files changed, 91 insertions(+)
>
> diff --git a/documentation/dev-manual/sbom.rst b/documentation/dev-manual/sbom.rst
> index 95303ed..6aa771e 100644
> --- a/documentation/dev-manual/sbom.rst
> +++ b/documentation/dev-manual/sbom.rst
> @@ -64,6 +64,19 @@ more information in the output :term:`SPDX` data:
>
> - Add archives of these source files themselves (:term:`SPDX_ARCHIVE_SOURCES`).
>
> +- Exclude specific files from the SPDX output using Python regular expressions
> + (:term:`SPDX_FILE_EXCLUDE_PATTERNS`).
> +
> +- Attach supplier information to the image SBOM, SDK SBOM, or individual
> + packages (:term:`SPDX_IMAGE_SUPPLIER`, :term:`SPDX_SDK_SUPPLIER`,
> + :term:`SPDX_PACKAGE_SUPPLIER`).
> +
> +- Enrich source downloads with ecosystem-specific Package URLs (PURLs), using
> + the :ref:`ref-classes-cargo_common`, :ref:`ref-classes-go-mod`,
> + :ref:`ref-classes-pypi`, :ref:`ref-classes-npm`, and
> + :ref:`ref-classes-cpan` classes to automatically populate PURL identifiers
> + for the corresponding language ecosystems.
> +
No mention of SPDX_INVOKED_BY/SPDX_ON_BEHALF_OF/SPDX_INCLUDE_BITBAKE_PARENT_BUILD?
> Though the toplevel :term:`SPDX` output is available in
> ``tmp/deploy/images/MACHINE/`` inside the :term:`Build Directory`, ancillary
> generated files are available in ``tmp/deploy/spdx/MACHINE`` too, such as:
> diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
> index 9e0c5b0..6f1b5a9 100644
> --- a/documentation/ref-manual/variables.rst
> +++ b/documentation/ref-manual/variables.rst
> @@ -9063,6 +9063,19 @@ system and gives an overview of their function and contents.
> }
> ],
>
> + :term:`SPDX_FILE_EXCLUDE_PATTERNS`
> + A space-separated list of Python regular expressions used to exclude files
> + from the SPDX output. Files whose paths match any of the patterns (via
I assume this variable only makes sense with SPDX_INCLUDE_SOURCES is set, right?
Maybe you could make that clear by saying it in the first sentence explicitly?
"""
A space-separated list of Python regular expressions used to exclude files
from the SPDX output when :term:`SPDX_INCLUDE_SOURCES` is enabled.
"""
> + ``re.search``) will be filtered out from the generated SBOM.
> +
> + By default this variable is empty, meaning no files are excluded.
> +
> + Example usage::
> +
> + SPDX_FILE_EXCLUDE_PATTERNS = "\.patch$ \.diff$ /test/ \.pyc$ \.o$"
> +
> + See also :term:`SPDX_INCLUDE_SOURCES`.
> +
> :term:`SPDX_INCLUDE_COMPILED_SOURCES`
> This option allows the same as :term:`SPDX_INCLUDE_SOURCES` but including
> only the sources used to compile the host tools and the target packages.
> @@ -9161,6 +9174,41 @@ system and gives an overview of their function and contents.
> increases the SBOM size (potentially by several gigabytes for typical
> images).
>
> + :term:`SPDX_IMAGE_SUPPLIER`
> + The base variable name describing the Agent (organization or person) who
> + supplies the image SBOM. When set, the supplier will be attached to all
> + root elements of the image SBOM using the ``suppliedBy`` property.
> +
> + This variable acts as a prefix for a group of sub-variables that together
> + describe the supplier agent. For example, setting
> + ``SPDX_IMAGE_SUPPLIER = "SPDX_IMAGE_SUPPLIER"`` enables the following
> + variables:
> +
> + - ``SPDX_IMAGE_SUPPLIER_name`` — display name of the supplier
> + - ``SPDX_IMAGE_SUPPLIER_type`` — agent type (``organization`` or ``person``)
> +
> + Example::
> +
> + SPDX_IMAGE_SUPPLIER = "SPDX_IMAGE_SUPPLIER"
> + SPDX_IMAGE_SUPPLIER_name = "Acme Corp"
> + SPDX_IMAGE_SUPPLIER_type = "organization"
From this I have a hard time understanding if I'm really supposed to set
SPDX_IMAGE_SUPPLIER to "SPDX_IMAGE_SUPPLIER" (a variable that contains its
variable name as a value)? Why is this needed?
Isn't setting:
SPDX_IMAGE_SUPPLIER_name = "Acme Corp"
SPDX_IMAGE_SUPPLIER_type = "organization"
enough?
Would setting SPDX_IMAGE_SUPPLIER to any other value work?
Maybe I'm missing something! :)
> +
> + If not set, no supplier information is added to the image SBOM.
> +
> + See also :term:`SPDX_PACKAGE_SUPPLIER` and :term:`SPDX_SDK_SUPPLIER`.
> +
> + :term:`SPDX_INVOKED_BY`
> + The base variable name describing the Agent that invoked the build.
> + Builds will be linked to this agent if specified. Requires
> + ``SPDX_INCLUDE_BITBAKE_PARENT_BUILD`` to be set.
"""
Requires :term:`SPDX_INCLUDE_BITBAKE_PARENT_BUILD` to be set to "1".
"""
We would also need a quick description of SPDX_INCLUDE_BITBAKE_PARENT_BUILD in
the glossary, which can be a copy of the class' [doc] flag + references to all
dependent variables (SPDX_ON_BEHALF_OF/SPDX_INVOKED_BY/SPDX_BUILD_HOST. Would
you mind adding it to your patch?
Also, could you provide an example?
> +
> + .. note::
Reading the sentence below, I'd convert this to a '.. warning::' block.
> +
> + Setting this variable will likely result in non-reproducible SPDX
> + output, because the invoking agent identity will vary across builds.
> +
> + See also :term:`SPDX_ON_BEHALF_OF`.
> +
> :term:`SPDX_LICENSES`
> Path to the JSON file containing SPDX license identifier mappings.
> This file maps common license names to official SPDX license
> @@ -9189,12 +9237,31 @@ system and gives an overview of their function and contents.
> and the prefix of ``documentNamespace``. It is set by default to
> ``http://spdx.org/spdxdoc``.
>
> + :term:`SPDX_ON_BEHALF_OF`
> + The base variable name describing the Agent on whose behalf the invoking
> + Agent (:term:`SPDX_INVOKED_BY`) is running the build. Requires
> + ``SPDX_INCLUDE_BITBAKE_PARENT_BUILD`` to be set.
Could you provide an example?
> +
> + .. note::
Again, reading the sentence below, I'd convert this to a '.. warning::' block.
> +
> + Setting this variable will likely result in non-reproducible SPDX
> + output.
> +
> + See also :term:`SPDX_INVOKED_BY`.
> +
> :term:`SPDX_PACKAGE_URL`
> Provides a place for the SPDX data creator to record the package URL
> string (``software_packageUrl``, in accordance with the Package URL
> specification) for a software Package. The default value of this variable
> is an empty string.
>
> + :term:`SPDX_PACKAGE_SUPPLIER`
> + The base variable name describing the Agent who supplies the artifacts
> + produced by the build. Works identically to :term:`SPDX_IMAGE_SUPPLIER`
> + but applies to individual packages rather than the image SBOM.
One question for me here is: where should I set these variables?
I would guess:
- SPDX_IMAGE_SUPPLIER in the image recipe
- SPDX_PACKAGE_SUPPLIER in any software recipe
- SPDX_SDK_SUPPLIER in the image recipe
?
This would need to be stated in the definitions.
> +
> + See also :term:`SPDX_IMAGE_SUPPLIER` and :term:`SPDX_SDK_SUPPLIER`.
> +
> :term:`SPDX_PACKAGE_VERSION`
> This variable controls the package version as seen in the SPDX 3.0 JSON
> output (``software_packageVersion``). The default value for this variable
> @@ -9211,6 +9278,17 @@ system and gives an overview of their function and contents.
> this option is recommended if you want to inspect the SPDX
> output files with a text editor.
>
> + :term:`SPDX_SDK_SUPPLIER`
> + The base variable name describing the Agent who supplies the SDK SBOM.
> + When set, the supplier will be attached to all root elements of the SDK
> + SBOM using the ``suppliedBy`` property.
> +
> + Works identically to :term:`SPDX_IMAGE_SUPPLIER` but for SDK builds.
You mean image-based SDKs, right? (-c populate_sdk).
You can also build generic SDKs with `bitbake meta-toolchain`. Would that
variable apply to it too?
> +
> + If not set, no supplier information is added to the SDK SBOM.
> +
> + See also :term:`SPDX_IMAGE_SUPPLIER` and :term:`SPDX_PACKAGE_SUPPLIER`.
> +
> :term:`SPDX_UUID_NAMESPACE`
> The namespace used for generating UUIDs in SPDX documents. This
> should be a domain name or unique identifier for your organization
Thanks a lot!
Antonin
next prev parent reply other threads:[~2026-03-19 8:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 8:57 [docs][PATCH] ref-manual/dev-manual: document new SPDX variables and capabilities stondo
2026-03-19 8:47 ` Antonin Godard [this message]
2026-03-20 12:56 ` [PATCH v2] " stondo
2026-03-23 9:13 ` Antonin Godard
2026-04-07 13:11 ` Antonin Godard
2026-04-07 13:11 ` [docs][PATCH] " Antonin Godard
2026-04-07 13:15 ` Antonin Godard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DH6MMYTW9EGG.1Y32J8PZPX2T8@bootlin.com \
--to=antonin.godard@bootlin.com \
--cc=Peter.Marko@siemens.com \
--cc=adrian.freihofer@siemens.com \
--cc=docs@lists.yoctoproject.org \
--cc=jpewhacker@gmail.com \
--cc=stefano.tondo.ext@siemens.com \
--cc=stondo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox