All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.