3 ms·

GitHub docs > Signing tags: https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-tags https://docs.github.com/en/authentica

GitHub docs > Signing tags: https://docs.github.com/en/authentication/managing-commit-signature-verification/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 https://git-scm.com/book/ms/v2/Git-Tools-Signing-Your-Work : $ git commit -S -m 'Signed commit'

jayknight 1y ago
But you can still delete and recreate/sign the same tag again.
- TingPing 1y ago
  But GitHub has the option to prevent this. Just like branches.
- westurner 1y ago
  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-account-compromise-with-sigstore-ee299dca5144/ 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-sigstore-de1ed745f6fc/ 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/use-artifact-attestations/use-artifact-attestations#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

jayknight 1y ago

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

TingPing 1y ago
But GitHub has the option to prevent this. Just like branches.
westurner 1y ago
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-account-compromise-with-sigstore-ee299dca5144/ 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-sigstore-de1ed745f6fc/ 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/use-artifact-attestations/use-artifact-attestations#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