cli: Support using other Sigstore instances

[jku]

I started prototyping #1546 and I think this turned out quite nice (since all of the internals already support this).

Summary

We already support --staging to change the used sigstore instance (and --trust-config to completely manually define the instance) but supporting any sigstore instance would be nice (it would also be directly useful in the root-signing testing as that essentially uses other sigstore instances like https://sigstore.github.io/root-signing/).

The complication is that there are two separate things that need to be supported:

1. initializing trust to a new instance
2. doing a sigstore action (sign/verify/...) with that instance

This PR solves this by adding a top level subcommand trust-instance for 1 and a flag --instance for 2. The former takes a TUF root metadata file and latter takes the URL as argment. I think this is the best compromise as

• trust only needs to be provided once, it will then be cached
• Provided trust will only be used if the --instance flag is used so there is never any accidental or unexpected trust
• --staging is now basically a shortcut for --instance https://tuf-repo-cdn.sigstage.dev and likewise you could say that the default is --instance https://tuf-repo-cdn.sigstore.dev

Similar implementations

Other clients have similar functionality: cosign via cosign initialize and sigstore-js with sigstore initialize but these have the unpleasant side effect of modifying the default that the client uses from that point on: I think this is a bad idea and requiring a --instance ... flag on every command is better. Users who want to always use a private instance should write a wrapper over sigstore-python to do that.

example

$ # The example unsafely fetches root for demonstration purposes only
$ URL=https://sigstore.github.io/root-signing
$ curl -o root.json $URL/13.root.json
$ sigstore --instance $URL trust-instance root.json
$ sigstore --instance $URL sign README.md

Review items

• names: I'm not sure if "instance" is a great name (but I also did not want "TUF" in there since that's an implementation detail). I wish we had used trust.sigstore.dev as the tuf url to make it clearer but 🤷.
• error checks on trust-instance:
  • currently both incorrect root metadata and incorrect instance URL lead to an error message about a failed tuf refresh, --verbose will show a stack trace that looks useful. I think that's reasonable.
  • trying to initialize trust again for an already trusted repository works -- but the embedded trust overrides this: so the embedded roots for sigstore.dev and sigstage.dev will always be used and cannot be "overwritten"
• sub-command location: we could hide the subcommand under plumbing too: sigstore plumbing trust-instance but that does not feel quite right
• do we want to expose the currently trusted instances somewhere in UI? I don't think it's really necessary (since you can't accidentally use an instance) but we could print the URLs and the local metadata paths somewhere (like sigstore trust-instance --list)

[jku]

A note on the security aspect here: the instances with embedded trust roots (currently sigstore.dev, sigstage.dev) are more secure than instances trusted with trust-instance:

• there is less chicken-and-egg problem with establishing trust as root.json comes with sigstore-python
• if sigstore-python is installed in non-user-writable location (such as part of the OS install), the embedded roots are better protected than the ones that are runtime trusted (as runtime trusted roots necessarily have to remain in user-writable locations)
• the embedded roots are always used when available: trust roots for those instances cannot be overwritten with trust-instance

[di]

LGTM with/without my suggestions.

[jku]

Thanks for comments: I updated the help texts with "Mutually exclusive with other instance configuration arguments", and maybe finally got check-README to approve...

[woodruffw]

Thanks @jku!