Ergonomic way to request certificate/signature files for multiple input files in v2

[sethmlarson]

In v1.x of Sigstore, you could sign multiple files and receive all output files by default based on the name of the input file (ie Python-3.11.5.tgz -> Python-3.11.5.tgz.sigstore, etc).

In v2.x, the only default file is the bundle. To also generate crt/sig files you must supply --certificate and --signature, but those options require a filename. There's no way (that I can find) to opt-in to receive those files with their default names.

To provide a suggestion on a potential addition of this feature: allow --certificate and --signature to be provided as flags without a filename to receive the default behavior?

Calling sigstore multiple times is a work-around for this problem (once per artifact, supplying the names yourself). I don't necessarily consider this issue a blocker since it can be worked around, but would require using SIGSTORE_IDENTITY_TOKEN environment variable to avoid needing to request identity from verifier multiple times.

[woodruffw]

Thanks for filing @sethmlarson!

Is the context for this the CPython release process? I think our long-term plan with sigstore-python (and Sigstore clients more generally) is to de-emphasize the individual certificate and signature outputs, since they're harder to use correctly versus the bundle (more opportunities for confusion, no inclusion proofs/promises, etc.).

That being said, we could maybe notch this under the same idea as in #718 -- we could add another command (like sigstore plumbing debundle foo.bundle bar.bundle) that would perform these extractions.

[sethmlarson]

It is in the context of the CPython release process, we'd like to adopt v2 but I noticed this while testing out the sigstore-python release candidates. The current guidance for Python+Sigstore doesn't mention bundles (but I would also like to move to them wholesale) so we might not want to immediately stop publishing crt/sig files.

If this is decided to not be a blocker we can work around it, just wanted to report it in case there were thoughts about this.

[di]

My two cents: I'd prefer to move forward to better support bundle files (possibly including support for backfilling by bundling existing sig/crt files) rather than make changes to continue to enable sig/crt files generation.

[woodruffw]

Got it, makes sense 🙂

@di might have opinions as well beat me to it, but I think we should consider this a non-blocker for 2.0 -- it'll be a feature re-addition in a new form, so we could possibly queue it up for 2.1 if it'll make your life on the CPython release side easier.

(My thinking there is that we'll want to do all of this plus #718 at once, by introducing a new sigstore plumbing subcommand namespace that integrators like CPython will find useful.)

[di]

@sethmlarson One last thought: if the CLI is not giving you what you need in the short term here, there's always the importable API, which should let you do this with a short Python script.

[woodruffw]

Closing per #1183.