-
Notifications
You must be signed in to change notification settings - Fork 598
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
SPDX-json output differs between cli and golang implementation #1213
Comments
Hi @ckotzbauer -- it looks like the only differences are the element IDs likely from the related files section, is that right? Is this a diff from |
Yes, this should be right.
No this is a diff between my go-implementation (linked above) which uses 0.56.0 in a PR and the 0.56.0 cli.
The fixtures were updated on my machine locally, not pushed yet. But the diff was created from up-to-date fixtures (generated by 0.56.0 syft cli) |
Ok, so you generate SBOMs using the command line If this gets run multiple times does it always result in the exact same diff? I suspect there may be a sorting issue specific to SPDX, probably nothing you need to change. |
Exactly.
I have to check this, will reply. |
@kzantow When running my go-code and the cli multiple times, the ordering always differs. |
@ckotzbauer thanks for getting back to me -- that is what I suspected, I think I have a fix for this. Are you able to test changes from a Syft PR somehow? |
yes, that should be possible 👍 |
@ckotzbauer I've created a PR here: #1216 ... to be frank, I'm not quite sure yet how to add a meaningful test for this yet so it might take just a bit to get it merged, but it would be nice to know if it seems to solve your problem |
great, I will test it with my code. |
The PR fixed the issue ✔️. My tests are green again. Tested the snapshotted cli against my go-code which also used the PR-code. |
You can also try to test the code against a static fixture. When the issue occurrs again, this will fail. |
Right, my concern is that we have some static fixtures that have been routinely passing... I'm not sure if they had sufficient data to exhibit the problem. Thanks for following up 👍 |
Thanks for the fast PR! |
I went ahead and published a new release with the fix here, please let me know if it doesn't work! https://github.com/anchore/syft/releases/tag/v0.57.0 |
@ckotzbauer -- there was a pretty obvious omission in the aforementioned refactor, so this will be fixed with PR #1350 and I've adjusted the tests to hopefully surface this more obviously in the future. |
Thanks @kzantow for your very quick reply!! |
@ckotzbauer -- a new Syft release |
Great. I can confirm, that the issue is now gone. Thanks for your work! 🥳 |
What happened:
Hi all,
I'm the maintainer of the https://github.com/ckotzbauer/sbom-operator project. Syft is integrated there via its golang api. This is unit-tested to ensure, that my code and the cli of the same version produce the same SBOM for images. Since 0.56.0 the spdxjson-output differs. (with 0.55.0 the syftjson format also differed, but that was fixed with 0.56.0).
What you expected to happen:
My code and the cli produce the same SBOM for images.
How to reproduce it (as minimally and precisely as possible):
Used image:
alpine@sha256:21a3deaa0d32a8057914f36584b5288d2e5ecc984380bc0118285c70fa8c9300
Used format:
spdxjson
SPDX-json from go-integration
Differences to CLI-Output
Note: Differences like
name
,creationInfo
ordocumentNamespace
are ok and not part of my diff. The differences appear inhasFiles
andrelatedSpdxElement
properties.Anything else we need to know?:
Maybe I have to change something from my code which fixes the differences, then please let me know 😉.
Environment:
syft version
:cat /etc/os-release
or similar):The text was updated successfully, but these errors were encountered: