[westurner]

GitHub docs > Signing tags: https://docs.github.com/en/authentication/managing-commit-si... :

> 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 book > 7.4 Git Tools - Signing Your Work: https://git-scm.com/book/ms/v2/Git-Tools-Signing-Your-Work :

  $ git commit -S -m 'Signed commit'

[jayknight]

But you can still delete and recreate/sign the same tag again.

[westurner]

Sigstore.dev supports revocation:

"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

If it is not possible to retract/revoke releases then, there again, the installer MUST verify against a signed list of revoked releases

[TingPing]

But GitHub has the option to prevent this. Just like branches.