Skip to content

spdx 3 support - #49

Draft
Avus-c wants to merge 25 commits into
mainfrom
dev/spdx-3-support
Draft

spdx 3 support#49
Avus-c wants to merge 25 commits into
mainfrom
dev/spdx-3-support

Conversation

@Avus-c

@Avus-c Avus-c commented Jan 18, 2026

Copy link
Copy Markdown
Collaborator

(will eventually) closes #48

First iteration will implement the spdx lite profile. All unused argument we'll ignore for now and add them later on one by one when needed. Hopefully we can keep the api free of breaking changes, although the resulting file will be completely different.

Few things to note on the current progress:

  • generated file is not valid json or spdx3 yet, and some requried information is not yet serialized.
  • there a few things that might be not easily convertable from spdx 2 -> spdx3
  • seems like we can update to sdpx3 without breaking api. Although I can't guarantee it for now.
  • The verifier used in the pipeline needs to be replaced. spdx got multple tools in different languages to verify generated documents and their java tool seems to be the only one that has full support for spdx3. (although their documentation and tool disagree on some property names.... which adds a lot of fun while working on it....)
    • using the tool locally until I'm somewhat finished with the migration, then will integrate it in ci.
  • doc needs updateing later on aswell
  • using UUIDs for spdx id, but these are likely to be replaced by uri, which are easier the read and make the document easier to read and reason over.

Update:

  • The spdx lite profile is close to being fully implemented and spdx3 compliant. There are still some formatting issues and the spdxid generation goes haywire for relationships. Everything else need for the lite profile is done.
  • switched the spdxid generation from UUIDs to something URI based, not fully finished yet, but almost done.

Avus-c added 17 commits January 8, 2026 15:39
... to avoid potential conflicts
... to differentiate between our messages and the rest.
Implemnted using a macro around cmakes message command.
Still partially broken (not valid json) and some information is not yet serialized.
For the most part the serialization is migrated though there a few that might not
be trivially possible.
Makeing the output valid json shouldn't be to difficult. I've deliberatly ignored it
to focus on converting stuff to spdx3.
SPDX3 requires all sbom elemets to be listed in a seperate json array. Every element added to the sbom, adds it's spdxid to a variable available during cmake-install through it's install script. These lists are then finalized at the end and inserted into the generated sbom.
because we generate cmake code during configure stage that need to run at install stage, we sometimes have to write strings with multiple levels of escaping.

With this helper function this can be done whenever necessary and not at the point where we are generating strings
this is not fully fleshed out yet, but the idea is to generate spdxids based on the path of the object in the sbom tree instead of using uuids. This should make it easier to read and understand the generated spdxids and also make it easier to correlate them with the structure of the sbom.
a single license defintion for each License.
packages and files refernce the license using relations(not yet implemented)
@Avus-c
Avus-c force-pushed the dev/spdx-3-support branch from 387ecdd to 82d020c Compare February 22, 2026 23:31
Avus-c added 3 commits March 1, 2026 20:43
also remvoe ability to set SPDXID manually.
I don't think this fits in the scope of this project,
and is not worth the complexity.
used for testing not allowed in sbom
using fixtures for a better testing approach and workflow
The filepath of the generated sbom is giving me a bunch of
headeachs. It's not possible to get the filepath where i need it,
and wildcard don't work for some reason. Probably cmakes "fault".
The only documented "Wildcards are not supported" in for cmake -E copy,
which is not at all what i am doing in add_test ...
@Avus-c
Avus-c force-pushed the dev/spdx-3-support branch from c86e6f3 to 52cd66a Compare March 3, 2026 23:04
martingo and others added 5 commits April 9, 2026 14:32
use the new verifier in ci, if java is not available
skip verification step
this also adds a check that spdx ids are unique by default.
In some instances, such as with licenses, the same spdx id
may be generated multiple times. To allow this, the ALLOW_DUPLICATES option
can be used to bypass the uniqueness check.

spdx3 also has a directory filetype property which we do not currently support.
@Avus-c

Avus-c commented Jun 17, 2026

Copy link
Copy Markdown
Collaborator Author

Regarding this pull-request (and maybe this project in general):

CMake introduced (experimental) SBOM generation capabilities with CMake 4.3.

I would like to avoid having an additional implemention that will largely do the same thing, especially when the potential support on kitwares end is much greater.
I will be checking the impementation in cmake and see what features it offers (now and in the future). Currently cmakes buildin implementation is missing quite a lot of things our implementation has/can do.

And sorry for the slow progress the last months, alot has been going on...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support SPDX 3.0

2 participants