My instant reaction was: "Wait?! They weren't immutable before?"
I'm glad they're doing this, and it's an unpleasant surprise that they didn't already work this way. I don't understand why they allow mutable releases.
replies(6):
I'm glad they're doing this, and it's an unpleasant surprise that they didn't already work this way. I don't understand why they allow mutable releases.
> You can sign tags locally using GPG, SSH, or S/MIME
$ git tag -s MYTAG -m "Signed tag"
# Creates a signed tag
$ git tag -v MYTAG
# Verifies the signed tag
$ git commit -S -m 'Signed commit'"Don’t Panic: A Playbook for Handling Account Compromise with Sigstore" (2022) https://blog.sigstore.dev/dont-panic-a-playbook-for-handling...
"Why you can’t use Sigstore without Sigstore" (2023) https://blog.sigstore.dev/why-you-cant-use-sigstore-without-... :
> Revocation in Sigstore. A recent post on this blog notes that signatures alone don’t tell you whether to trust an artifact; for that, you need a verification policy. This verification policy is a much more natural place to handle revocation than the identity layer; see Don’t Panic for an example. This allows us to avoid the scalability problems of global revocation lists (see CRLite for a discussion of these issues). The mantra here is revoke artifacts, not keys.
Artifact Attestation > Verifying an artifact attestation for binaries: https://docs.github.com/en/actions/how-tos/secure-your-work/... :
gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R orgname/reponame