-
Notifications
You must be signed in to change notification settings - Fork 28
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
Fix SBOM generation inconsistency #61
Fix SBOM generation inconsistency #61
Conversation
Can you elaborate about where you ran into this?
This approach has the downside of being destructive with regards to InternalCompatibilityFlags, though, right? If I change the config.json and just add another flag in InternalCompatibilityFlags, it would show up as the same SBOM? That does not sound good. Maybe this should be fixed in a different place instead? |
Sure. It is 100% of the time reproducible for me.
Aside from the pointers (which cause diff in the byte representation of the The remaining diff is caused by the
As you can see the difference is in the This happens because in the gok packer logic we dynamically set the flag: tools/internal/packer/packer.go Lines 1008 to 1011 in 23cde3b
Yes good point, given those are internal flags for migrating from gokr-packer to gok (and configure the CLI meta options), I figured they wouldn't necessarily mean anything from an image build perspective, but I see your point. What would you suggest then? Should we set |
Thanks for the details. I think in this particular case it would actually be best to:
…and avoid the diff that way. |
a2bde28
to
2b0f193
Compare
Yes, that makes sense to me. I've created a PR for the accessor change here: gokrazy/internal#18 Once the accessor PR merges we'll need to remove. the replace directive before merging this PR. |
2b0f193
to
04180ad
Compare
prior to this commit SBOMs would have inconsistency in their hashing on the configuration file. The representation of the config file in fact would differ at certain stages of the gok commands lifecycle, where at packer running time, an extra InternalCompatibilityFlag, Sudo, would be added in memory (while that not being the case at `gok sbom` time), resulting in a differing config and as such differing SBOM hashes, same goes for the differing pointer addresses that were skew the hashing results. This is now fixed by removing the InternalCompatibilityFlag set (using an accessor) from the config prior to its hashing, as well as converting the config into a string before performing the hash computation, to avoid differing pointer problems.
04180ad
to
0344caa
Compare
Replace directive removed and newest |
Currently SBOMs may have inconsistent hashing of the configuration file.
The representation of the config file in fact may differ at certain stages of the gok commands lifecycle, where at packer running time for example, extra InternalCompatibilityFlags would be added in memory (while that not being the case at
gok sbom
time), resulting in a differing config and as such differing SBOM hashes. The same would happen due to the differing pointer addresses in the config that resulted in differing hashing results.This is now fixed by removing the InternalCompatibilityFlags from the config prior to its hashing, as well as converting the config into a string before performing the hash computation, to avoid hashing pointers problems.