sigstore
`--cert-identity` should be optional on `sigstore verify github`
Noticed while dogfooding with @ret2libc: sigstore verify github currently requires --cert-identity, even when the set of flags passed by the user might be sufficient for verification purposes.
This makes sigstore verify github invocations unnecessarily wordy, e.g.:
sigstore verify github action.py --cert-identity https://github.com/sigstore/gh-action-sigstore-python/.github/workflows/release.yml@refs/tags/v2.0.1
...when, for many users, this more concise invocation is probably sufficient:
sigstore verify github action.py --repository sigstore/gh-action-sigstore-python
(This would be a backwards-compatible change, since --cert-identity would go from required to optional.)
Are these equivalent identifiers? The former is a specific "builder" identity. This aligns to SLSA's model for identity, that trust is rooted in the builder. In terms of trust boundary however, you could argue that a maintainer can modify any workflow in a repository, so it's unnecessary to pin to a specific builder.
Preferring the more narrowly scoped identity, could we specify an additional flag for "releaser" or "builder" like release.yml@refs/tags/v2.0.1, and then combine repository with this flag to construct the identity?
Sorry, I completely missed this comment before 😅
Are these equivalent identifiers? The former is a specific "builder" identity. This aligns to SLSA's model for identity, that trust is rooted in the builder. In terms of trust boundary however, you could argue that a maintainer can modify any workflow in a repository, so it's unnecessary to pin to a specific builder.
Yeah, I think the argument here would be that, especially in the absence of strongly pinned reusable workflows, there's very little auditable difference between a ref + workflow filename and the repository URI itself -- in both cases you need to resort to checking the exact build commit anyways, since the repository can move both the filename and symbolic ref around as it pleases.
(I suspect this is gh attestation's rationale as well, since they allow scoping as high as just the GitHub org without referencing the repo or workflow, etc.)