On 6/3/26 6:35 AM, Richard Purdie via lists.openembedded.org wrote:
On Wed, 2026-06-03 at 13:22 +0200, Marta Rybczynska via lists.openembedded.org
wrote:
Because of this, I believe the minimum information that should be included in
the generated SBOM is:
* The list of layers used for the build.
* The version or revision of each layer.
* Potentially the exact source revision used for each layer repository.
It may also be worth considering whether layers should have a more explicit
and consistently available versioning mechanism... (but that in step 2)
When we have the list of layers, we also have information on bbappends, so
that does not need to be directly present.
Some of this (or most) is available with SPDX_INCLUDE_BUILD_VARIABLES = "1" and
SPDX_INCLUDE_BITBAKE_PARENT_BUILD = "1", but in a non-standard and
non-portable way.
What do you think?
I'm worried about this since it implies every time you update your metadata, you
have to regenerate every spdx file. You update oe-core, it changes the top level
README and everything would then have to rebuild. It also means the spdx sstate
is never reusable without the exact same layer config, you can't add or remove
any layer and have reuse work, even if that layer has no effect on the recipes
in question.
So whilst I see why you might want this information in there, it would
effectively destroy some of the key things OE brings to the builds.
This is really what the task hashing is supposed to accomplish, combine the
build environment, metadata and related into something that indicates a build
changed or not. While it doesn't indicate the contents of the configuration, it
does indicate it changed.
Is there any way we can incorporate not the hash itself, but what the hash
indicates that something built into the recipe SDPX files? (I can't think of
anything right off the top of my head.)
When the recipe SPDX files are rolled up into a filesystem SBOM though, we could
include specific build information, as we know that a "new" build would change
the filesystem hashes and cause a rebuild anyway.
--Mark
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2379):
https://lists.openembedded.org/g/openembedded-architecture/message/2379
Mute This Topic: https://lists.openembedded.org/mt/119626760/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
