Blunt update of SPDX version 2.2 -> 2.2.2

microsoft / sbom-tool

The SBOM tool is a highly scalable and enterprise ready tool to create SPDX 2.2 compatible SBOMs for any variety of artifacts.

MIT License

1.63k stars 133 forks source link

Blunt update of SPDX version 2.2 -> 2.2.2 #767

Closed bact closed 3 weeks ago

bact commented 3 weeks ago

This is a blunt and aggressive approach of making sbom-tool supporting SPDX 2.2.2 (in order to fix #738).
It does not add 2.2.2 support AND keep 2.2 support, it is replacing 2.2 with 2.2.2. There will be no 2.2.
It is basically replacing the version number (SPDXConstants.SPDXVersion) from "2.2" to "2.2.2" when creating SbomSpecification.
As there's no technical differences between 2.2, 2.2.1, and 2.2.2, this can be a minimal way to support 2.2.2.
Considering 2.2.2 is a patch version of 2.2 (and there's no technical differences), we may able to say it is still "supporting" 2.2.

KalleOlaviNiemitalo commented 3 weeks ago

Does this make sbom-tool Generate -ManifestInfo SPDX:2.2 an error and require SPDX:2.2.2 instead? If so, that's a breaking change and I hope it will be well documented. It should then be changed here too: https://github.com/microsoft/sbom-tool/blob/552c36ccc69ab5c833aae4b6376633b1cdd7d62b/src/Microsoft.Sbom.Targets/Microsoft.Sbom.Targets.targets#L31

Currently, Microsoft.Sbom.Targets 3.0.0 places the SBOM at _manifest/spdx_2.2/manifest.spdx.json within the generated NuGet package. In the future, as the SBOM tool is updated for subsequent versions of SPDX, are consumers of NuGet packages expected to enumerate the subdirectories of _manifest rather than assume this path?

bact commented 3 weeks ago

@KalleOlaviNiemitalo I assume and expect that this command

sbom-tool Generate -ManifestInfo SPDX:2.2

will just generate an SBOM with SBOMSpecification("SPDX", "2.2.2") (and any 2.2.x, as a feature-compatible version of 2.2), using spdx_2.2 folder.

But, yes, if it is an error, it will be definitely a breaking change - which is not desired and we need a way support BOTH 2.2 and 2.2.2 at the same time down to the command-line (because scripts/workflow will rely on it).

DaveTryon commented 3 weeks ago

@KalleOlaviNiemitalo and @bact, we're discussing this internally to determine our best path forward. We have internal validation tooling that expects the spdx_2.2 folder, so that will break if we suddenly change the folder name to spdx_2.2.2 We haven't yet determined exactly how we want to proceed to provide the optimal experience.

@THEJRRR is the person driving the requirements, so I'm adding him to the thread.

DaveTryon commented 3 weeks ago

It's unlikely that we'll merge this PR. May I suggest moving the discussion to #738?

bact commented 3 weeks ago

Please move the discussion over. Thank you.