CLI: Provide a subcommand for creating bundles from detached materials?

[sethmlarson]

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 like sigstore 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.

[woodruffw]

Thanks @sethmlarson! I'm going to hijack the top-level comment here to copy over what I've written up (preserving your summary as well) 🙂

[woodruffw]

CC @di for opinions here, as well as @haydentherapper as a cosign maintainer (maybe you've had a similar problem/requirements?)

[haydentherapper]

The closest analogy in Cosign would be the cosign attach commands that upload detached metadata to a container in a registry. We're just starting to add bundle support in Cosign, so I haven't thought through this case, but I think that's a great suggestion.