Tag SHA issues

[henryiii]

Description

Hi,

After the recent litellm security breach involving force pushed tags, I've been trying to pin down CI in repos to SHA hashes. One key issue with that is that GitHub will resolve a hash to any fork, so I'm also making sure the human readable tag comments and SHAs match. This is an issue with this repo only, though: if I go to the release, I get that v1.44.0 resolves to 631208b. But if I ask for that from git, using git ls-remote --tags https://github.com/crate-ci/typos v1.44.0, I get a8d8e187146634c459c27ade2d3e338569378720 instead. Do you know why that is happening? That's not showing up as a valid SHA on the GH interface at all.

A previous issue I've also seen is that pre-commit.ci picks up the v1 tag instead of the specific tag, like v1.44.0 tag on every bump, causing it to do things like v1.43.0 -> v1 (moving tags are not supported by pre-commit, since it caches globally based on the rev). You can make v1 a branch instead of a tag, since it's being moved every release, perhaps?

Thanks for taking a look! (This is for pypa/packaging#1133, though I'll probably be doing it other places too)

[epage]

If you don't add a filter, you get

a8d8e187146634c459c27ade2d3e338569378720        refs/tags/v1.44.0
631208b7aac2daa8b707f55e7331f9112b0e062d        refs/tags/v1.44.0^{}

From the manpage

       When showing an annotated tag, unless --refs is given, two such lines are shown: one with the refname for
       the tag itself as <ref>, and another with <ref> followed by ^{}. The <oid> on the latter line shows the name
       of the object the tag points at.

A previous issue I've also seen is that pre-commit.ci picks up the v1 tag instead of the specific tag, like v1.44.0 tag on every bump, causing it to do things like v1.43.0 -> v1 (moving tags are not supported by pre-commit, since it caches globally based on the rev). You can make v1 a branch instead of a tag, since it's being moved every release, perhaps?

Changing anything about v1 will not help because there are more tags than just that because we develop everything in one repo and precommit refuses to support that workflow. Using prek should resolve that problem. See also #390.

[henryiii]

Ahh, interesting! So git ls-remote https://github.com/crate-ci/typos --tags 'v1.44.0' 'v1.44.0^{}' shows both. I guess I was unlucky and this was the only one using annotated tags? Thanks, appreciate the help!

[henryiii]

And Dependabot fails with the multiple tags, too:

pypa/packaging#1136

Since support for pre-commit in Dependabot is pretty new, opened an issue at dependabot/dependabot-core#14550.