You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi folks 👋 I have been working on a setup to run private Sigstore instances and one of the hurdles right now is how cosign initialize is executed by users. When providing the initial root via --root, they either:
Have to get the initial root.json through a side channel (it has to be pre-baked inside a CI image somehow, distributed through an IaC tool etc) or
They just reference it directly from its URL of the TUF repo for the --root argument (which arguably is not the safest thing to do)
Providing the initial root.json via a side channel is the better way to go, but it's also a bit inconvenient, because it requires distributing the whole file.
I think a more convenient way to handle this would be allowing to verify the checksum of the initial root instead of actually providing it. This would allow having a single C&P command to initialize cosign instead of having to distribute a file through a side channel. It would also make it more convenient for e.g. CI pipelines, where the checksum could be provided as a single env variable instead of having to bake in the whole root.json file into CI build images or individual repos.
In terms of implementation, I would propose adding a new --root-checksum argument, mutually exclusive with the existing --root argument. The format of the accepted value would be something like [[<root-file-name>:]<checksum-algo>:]<checksum>. Examples:
--root-checksum 1.root.json:sha512:abcde...
--root-checksum sha512:abcde... (implying 1.root.json as file to check)
--root-checksum abcde... (implying 1.root.json as file to check and sha512 as checksum algo to use)
I'm not sure if the root-file-name as part of the value is really necessary, so that might be omitted in the implementation, but maybe it's good to be able to override it?
If this makes sense, I would be happy to implement the feature and submit a PR. Please let me know what you think! 🙏
The text was updated successfully, but these errors were encountered:
I'm supportive of this, and would prefer this to be a requirement if a root is downloaded via URL, I agree that is quite unsafe. We can tee this up as a requirement for the next major release.
I'd lean towards simplicity, with --root-checksum being only a digest of the requested file from --root.
Description
Hi folks 👋 I have been working on a setup to run private Sigstore instances and one of the hurdles right now is how
cosign initialize
is executed by users. When providing the initial root via--root
, they either:root.json
through a side channel (it has to be pre-baked inside a CI image somehow, distributed through an IaC tool etc) or--root
argument (which arguably is not the safest thing to do)Providing the initial
root.json
via a side channel is the better way to go, but it's also a bit inconvenient, because it requires distributing the whole file.I think a more convenient way to handle this would be allowing to verify the checksum of the initial root instead of actually providing it. This would allow having a single C&P command to initialize cosign instead of having to distribute a file through a side channel. It would also make it more convenient for e.g. CI pipelines, where the checksum could be provided as a single env variable instead of having to bake in the whole
root.json
file into CI build images or individual repos.In terms of implementation, I would propose adding a new
--root-checksum
argument, mutually exclusive with the existing--root
argument. The format of the accepted value would be something like[[<root-file-name>:]<checksum-algo>:]<checksum>
. Examples:--root-checksum 1.root.json:sha512:abcde...
--root-checksum sha512:abcde...
(implying1.root.json
as file to check)--root-checksum abcde...
(implying1.root.json
as file to check andsha512
as checksum algo to use)I'm not sure if the root-file-name as part of the value is really necessary, so that might be omitted in the implementation, but maybe it's good to be able to override it?
If this makes sense, I would be happy to implement the feature and submit a PR. Please let me know what you think! 🙏
The text was updated successfully, but these errors were encountered: