3 ms·

Git tags aren’t even really immutable, they’re treated as such but they’re not.

by hk1337 1y ago

westurner 1y ago
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
kimixa 1y ago
Any "given" name/ID (IE anything but the full hash) in a distributed VCS has to be mutable - without some single central arbiter of truth it's simply impossible. I'm honestly a little surprised people seem to think they might be immutable - I guess maybe if people see "git" as "Actually Github"?

Git tags aren’t even really immutable, they’re treated as such but they’re not.

by hk1337 1y ago

Git tags aren’t even really immutable, they’re treated as such but they’re not.

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

kimixa 1y ago

Any "given" name/ID (IE anything but the full hash) in a distributed VCS has to be mutable - without some single central arbiter of truth it's simply impossible. I'm honestly a little surprised people seem to think they might be immutable - I guess maybe if people see "git" as "Actually Github"?