Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v0.3.0 SPDX SBOM Does Not Have Unique SPDXID Package IDs #923

Closed
jspeed-meyers opened this issue Mar 17, 2022 · 5 comments
Closed

v0.3.0 SPDX SBOM Does Not Have Unique SPDXID Package IDs #923

jspeed-meyers opened this issue Mar 17, 2022 · 5 comments
Assignees
Labels
bug Something isn't working I/O Describes bug or enhancement around application input or output

Comments

@jspeed-meyers
Copy link

jspeed-meyers commented Mar 17, 2022

What happened:

I was trying to convert the JSON format of the v0.3.0 SBOM to the tag-value format. The tool I was using reported multiple non-unique SPDXID package IDs and therefore did not work. For instance, there are multiple packages with the SPDXID of SPDXRef-Package-go-module-github.com/adrg/xdg-v0.3.3.

What you expected to happen:

I expected each package's SPDXID to be unique. See the SPDX spec: https://spdx.github.io/spdx-spec/package-information/ - The spec has this description of the Package SPDX identifier field: "Uniquely identify any element in an SPDX document which may be referenced by other elements."

How to reproduce it (as minimally and precisely as possible):

I was using this tool: https://github.com/spdx/tools-java with this command:
java -jar ../../external-tools/tools-java-1.0.4-jar-with-dependencies.jar Convert chronicle-sbom.spdx.json chronicle-sbom.spdx JSON Tag

Anything else we need to know?:

You could just say, "This isn't important." And that's fine! But I thought you might be curious and, additionally, it might lead to an upstream fix, if there is even a bug!, in syft.

@jspeed-meyers jspeed-meyers added the bug Something isn't working label Mar 17, 2022
@wagoodman
Copy link
Contributor

I think this was intended for anchore/syft , I'll transfer there.

Regarding the specific issue, in short, I agree. Originally our package IDs in the syft-json format were random IDs, so generating an SBOM from a source twice wouldn't produce the same SBOM. We eventually moved over to stable IDs that are based on the package definition, however, didn't update the package IDs created for SPDX to reference the new syft model IDs. We should probably change this.

The only other consideration not to do this is the fact that we could loose semantic usefulness of the IDs, but I think this is a secondary concern, and there are ways to solve that problem as well (if it is a problem).

@wagoodman wagoodman transferred this issue from anchore/chronicle Mar 28, 2022
@jspeed-meyers
Copy link
Author

Thanks, @wagoodman.

@jonasagx
Copy link
Contributor

Side note, @jspeed-meyers we released an experimental conversion feature in the latest syft, where you can convert from SPDX-json to tag-value by:

syft convert chronicle-sbom.spdx.json -o spdx-tag-value

@luhring luhring added the I/O Describes bug or enhancement around application input or output label May 21, 2022
@spiffcs
Copy link
Contributor

spiffcs commented May 26, 2022

I'll start taking a look at this today to see how we can get more uniqueness in the ID, specifically the cases where SPDXRef-Package-go-module-github.com/adrg/xdg-v0.3.3 is a repeat value.

@spiffcs spiffcs self-assigned this May 26, 2022
@kzantow
Copy link
Contributor

kzantow commented Nov 8, 2022

Hi @jspeed-meyers sorry for the delay here, but this has actually been fixed for a while -- we're appending a unique hash to the SPDXIDs. I'm going to close this but please reopen if you continue to have any issues!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working I/O Describes bug or enhancement around application input or output
Projects
Archived in project
Development

No branches or pull requests

6 participants