Closed damdo closed 8 months ago
I wonder if it could be a viable strategy to calculate the SBOM before setting InternalCompatibilityFlags? That way, user-specified InternalCompatibilityFlags would still be reflected in the SBOM, but tool-specified InternalCompatibilityFlags would not.
Shower thoughts: an alternative to the approach of generate-sbom-before is to split up the user-provided vs. tool-specified InternalCompatibilityFlags into two separate fields and use accessors.
Or, the galaxy brain solution could be to get rid of all InternalCompatibilityFlags (one by one) and solve the problem that way.
Attempted approach 1 here: https://github.com/gokrazy/tools/pull/66
Turns out that https://github.com/gokrazy/tools/pull/61 only fixed the SBOM inconsistencies that were caused by config.Struct pointers and by the Sudo flag, that was set here. They did not fix the diff that is generated from the other fields in the
config.InternalCompatibilityFlags
, which I didn't realise, are set depending on the update mode.gok sbom
is used, noconfig.InternalCompatibilityFlags
are set.gok overwrite --full
is usedconfig.InternalCompatibilityFlags.Overwrite
andconfig.InternalCompatibilityFlags.TargetStorageBytes
are setgok overwrite --gaf
is used, nothing is setgok update
is used,config.InternalCompatibilityFlags.Udpdate
(optionally Insecure, Testboot) is set.These end up being accounted for when the
config.Struct
is stringyfied and formatted in hex, influencing the hash value for the config.json, ending up influencing the one of the final SBOM hash.This is an issue when
gok sbom
is used to check for changes between the running instance (SBOM) and the current local instance folder, as it results in different SBOM hashes, which in these cases might mean an infinite loop of unnecessary updates.Do you have any idea on how we could circumvent this issue?
I know @stapelberg mentioned that ignoring the
config.InternalCompatibilityFlags
that would mean same SBOMs for an instance with differingInternalCompatibilityFlags
, but I would prefer this poison versus having unusable SBOMs and unnecessary updates (unless we can come up with a better solution for this :)).WDYT?