Add features needed to sign SLSA Source Attestations

[TomHennen]

Description

The SLSA Source Track defines summary attestations as a way of attesting the high level properties of a source revision.

In addition it wants implementors to be able to create other more detailed provenance attestations.

gitsign seems like the perfect tool to be able to sign these attestations but I ran into a couple of problems when I tried signing a summary attestation.

1. The spec wants the subject to specify the git commit using a digest type of gitCommit (a standard in-toto type. However gitsign currently stores the git commit in a sha256 digest type.
2. The spec wants implementors to specify the branches as annotations on the subject. Currently gitsign doesn't offer any ability to specify annotations.
3. The spec wants the subject.uri to be set. Currently gitsign doesn't offer any ability to set the subject.uri field.
4. The spec wants the statement type to be set to "https://in-toto.io/Statement/v1" but currently gitsign uses "https://in-toto.io/Statement/v0.1"

It might be possible to resolve this by enable gitsign to take a 'raw' in-toto statement, but as @wlynch points out, that runs the risk of decoupling the commit referenced in the attestation from where gitsign is actually storing the data.

Instead, perhaps we can address this by updating gitsign to:

1. Set gitCommit in addition to the existing sha256 type (or alternatively have some flag to set it to a more modern mode).
2. Update the statement type to "https://in-toto.io/Statement/v1"
3. Add a command line flag for setting the subject URI (e.g. --subject_uri https://github.com/sigstore/gitsign/commit/9fc97de55fc1926fa2a76f06b02c8531dcf6828d)
4. Add a command line flag for adding subject annotations (e.g. --subject_annotation "source_branches=foo,bar")

In the end some might be able to sign a SLSA Source VSA with a command like:

gitsign attest -f vsa-predicate.json --type https://slsa.dev/verification_summary/v1 --subject_annotation "source_branches=foo,bar" --subject_uri https://github.com/sigstore/gitsign/commit/9fc97de55fc1926fa2a76f06b02c8531dcf6828d

Would something like this be reasonable?

Version
gitsign version v0.12.0

[wlynch]

Generally in favor of this! A few notes:

1. The spec wants the subject to specify the git commit using a digest type of gitCommit (a standard in-toto type. However gitsign currently stores the git commit in a sha256 digest type.

Set gitCommit in addition to the existing sha256 type (or alternatively have some flag to set it to a more modern mode).

Fine with me! I'm okay with making this as a breaking change - as evident by the recent fix of gitsign attest, I don't think many people are using this actively at the moment. This was a side-effect of leaning on the cosign libraries, but we can just as easily generate the attestations here in gitsign as well.

2. The spec wants implementors to specify the branches as annotations on the subject. Currently gitsign doesn't offer any ability to specify annotations.

Add a command line flag for adding subject annotations (e.g. --subject_annotation "source_branches=foo,bar")

LGTM!

3. The spec wants the subject.uri to be set. Currently gitsign doesn't offer any ability to set the subject.uri field.

Add a command line flag for setting the subject URI (e.g. --subject_uri 9fc97de)

I think I'm okay with this, mostly because the VSA spec says SHOULD.

I have mixed feelings about tying subjects to entities outside of the repo - putting my git-idealist hat on, because repos are distributed it would be nice if predicates could be true regardless of the remote you're pulling from (e.g. https://go.googlesource.com/go and https://github.com/golang/go should be the same repo).
I get this can be useful to tie verification to a given instance, but it almost feels like remotes should be the signers of an attestation in many cases. How that would be done TBD - bootstrapping trusted identities for repo metadata was the primary motivation for gittuf though, so I would look there for inspiration - cc @adityasaky.

That said, given this is not required I'm okay with exposing a optional flag to enable this for people who want it.

4. The spec wants the statement type to be set to "https://in-toto.io/Statement/v1" but currently gitsign uses "https://in-toto.io/Statement/v0.1"

Update the statement type to "https://in-toto.io/Statement/v1"

This should be easy to do, both here and in cosign (since they're using the same library), but we should coordinate with cosign folks to be safe. https://github.com/sigstore/cosign/blob/8040fc4b1dbf85cce1a40528a5be666388ad059c/pkg/cosign/attestation/attestation.go#L173