CLI: Full DSSE support

[woodruffw]

Right now, the sigstore CLI only has limited support for DSSE bundles: we support verifying them in sigstore verify, but not signing/generating via the CLI.

Some things we'll want to do:

• [x] #1115: We should support DSSE bundle generation and signing via the CLI. This will require some design thought on how best to integrate this with the current sigstore sign subcommand; two ideas:
  • sigstore sign --attest enables DSSE generation/signing, rather than the default hashedrekord
  • A new subcommand hierarchy, like sigstore attest ..., to mirror cosign attest
• [x] #1116: When verifying DSSE bundles with sigstore verify ... subcommands, we should support emitting the bundle's interior statement in a structured manner, for further processing.
  • One idea for doing this is to add a --format=json or similar flag across all of the verification subcommands, and have the subcommands emit only JSON in that case, e.g. {"valid": true, "statement": {...}}.
• [x] #1124: Generally improve our integration-level testing of the sigstore CLI

CC @facutuesca

[facutuesca]

I see that DSSE supports multiple artifacts (“subjects”) inside the envelope, each with a name and digest. But the current sigstore sign (non-DSSE) command will, given multiple input files, generate multiple bundle files, one for each input file.

Do we want the same behavior when using DSSE? That is, multiple input files -> multiple output bundles, even if a single DSSE envelope supports having multiple subjects? Or do we want to output a single sigstore bundle, that contains the DSSE envelope with multiple subjects?

[woodruffw]

Do we want the same behavior when using DSSE? That is, multiple input files -> multiple output bundles, even if a single DSSE envelope supports having multiple subjects? Or do we want to output a single sigstore bundle, that contains the DSSE envelope with multiple subjects?

The former -- I think we want to maintain the 1:1 relationship between input and output files for now, even though DSSE bundles technically allow a 1:N relationship. My rationale for that is that fewer clients support that 1:N pattern, and the 1:1 pattern is more immediately applicable to use cases like Python packaging 🙂

[facutuesca]

Do we want to use the same default predicate type for the in-toto statement as cosign? i.e: https://cosign.sigstore.dev/attestation/v1.

edit: I see that predicate is defined here, and it contains two fields: Data and Timestamp, where Data contains the contents of the file passed via the --predicate argument. Do we want to have the same behavior as cosign? By default using that predicate type (with Data and Timestamp fields), and then adding support for other predicateTypes?

[woodruffw]

Do we want to use the same default predicate type for the in-toto statement as cosign? i.e: https://cosign.sigstore.dev/attestation/v1.

IIRC our DSSE signing API already uses a different predicate type (one that's not cosign specific) by default, so I think we should probably default to that. If I'm remembering right, I picked the current predicate default based on the GitHub Attestations' feature's default.

Edit: whoops, I was thinking of the statement not the predicate type. IMO we should default to whatever GitHub's attestations use for their default predicate type, but also think about how we'll expose appropriate CLI flags for customizing the predicate during DSSE signing.

[woodruffw]

This is complete!