-
Notifications
You must be signed in to change notification settings - Fork 62
Description
Raised by @sethmlarson: previous versions of sigstore
produced "detached" verification materials (i.e. separate .crt
, .sig
, etc.), while current versions strongly encourage users to produce and emit Sigstore bundles (.sigstore
) instead.
Detached materials are still supported, but we'd like to eventually deprecate them. To do that, we need to give users a migration pathway: there should be an easy way to transform their pre-existing detached materials into a compliant bundle. Luckily for us, this is "easy" on an API level: any (cert, sig, input)
bundle can be converted into a bundle with relative ease by combining it with an online transparency log lookup and serializing the result.
The CLI part, on the other hand, needs some design consideration (since our CLI is a public interface and is subject to stability concerns). Some ideas:
- Create a new
sigstore plumbing
subcommand namespace, that explicitly contains lower-level operations like this one (which in turn can be deprecated and removed on a faster cadence). For example, this would be something likesigstore plumbing bundle <input>
. - Put it at the top-level like the other subcommands, but require some kind of
--internal
or--plumbing
flag to emphasize that it's not intended for ordinary use and that ordinary users should never need to interact with it.
Original submission:
Description
Currently on python.org/downloads we have a mix of releases that either have certificate/signatures separate or that with a bundle as well. We'd like to move to using bundles but in order to simplify the guidance we give users on verifying the release artifacts we'd like to backfill bundles to the releases that don't have bundles.
In order to accomplish this, I discussed on Slack with @woodruffw and we decided on a subcommand sigstore bundle
which would take a signature and certificate, do a TLog lookup similar to verifying, and then output a bundle from those materials.