Unfortunately this makes a mistake by using a short commit ID: "(e.g. a5b3abf)"
That's not a full commit ID, so it can still result in a mutable reference if either someone can find a clash[1] or if they can push a tag with that name and it takes priority in the context it is used (this is somewhat complex, e.g. GitHub prohibits pushes of branches and tags which are exactly 40 hex characters long, but other services may not).
Shortened commit SHAs are actually not supported by Actions; if you try, you get
"Unable to resolve action `actions/checkout@11bd719`, the provided ref `11bd719` is the shortened version of a commit SHA, which is not supported. Please use the full commit SHA `11bd71901bbe5b1630ceea73d27597364c9af683` instead."
What if the repository has a tag called 11bd719? Does Git/GitHub forbid creation of this tag if a commit exists with that prefix?
What if a Git commit is created that matches an existing tag? Does Git have a procedure to make a new one? e.g. imagine I pregenerate a few million 8 character tags and wait for a collision
btw: Even if you specify the full commit SHA, this can still be attacked; there have been pre-image attacks against Git commit hashes in the past. At least for older versions of Git, the algorithm was Sha1. Maybe that’s changed but an attacker could always construct a malicious repository with intentionally weak hashes with the intent of later swapping one of them. (But at that point they may as well just push the malicious code in the first place.)
What is the attack exactly? Only full commit SHAs are valid to reference a commit by SHA. GitHub disallows tags and branch names that could collide with a full commit SHA. There is never any collision between commit SHAs and tags.
I think the hypothetical attack is to create a tag with the shortened commit SHA pointing at malicious code, and if someone accidentally puts that instead of the full commit SHA, maybe Github will serve them that malicious tag instead of throwing the error. It sounds like that could work if Github doesn't block a tag/branch colliding with a shortened commit SHA. I'd guess they probably do though?
So you would need to specifically write an action referencing an invalid short SHA, which would not work and the action would fail, and then wait for an attacker to push an action with that tag name, and then run your action which has thus far been failing because of the invalid reference?
You'd push the tag at the same time you push the commit. If anyone tries to reference your action and accidentally copies the shortened commit SHA instead of the full commit SHA, they'll reference the malicious tag instead. They'd never see it fail, they'd just silently pick up the malicious tag. But again I'm guessing Github will block that shortened commit SHA as a tag and this wouldn't actually work.
How could they? They can't block every 8 character tag. And you can push the tag before you push the commit. (You know which short sha to impersonate because you can see it locally.)
Whilst Git will be default abbreviate commits to 7 characters, that's merely a default; `core.abbrev` can be set to any number to change the default display. Git will also accept any length abbreviated hashes as long as they're unique in the repo.
It's still SHA-1 by the way, but they included counter-cryptanalysis to reject objects that appear to be one side of a collision using known techniques.
So just so I'm clear based on what you've mentioned, even the policy prohibiting 40 hex character tags isn't doing anything to stop a tage the same as the short commit ID?
> the real renovate bot immediately took the exfiltration commit from the fake renovate bot and started auto-merging it (updating full SHA1 references)
That's not a full commit ID, so it can still result in a mutable reference if either someone can find a clash[1] or if they can push a tag with that name and it takes priority in the context it is used (this is somewhat complex, e.g. GitHub prohibits pushes of branches and tags which are exactly 40 hex characters long, but other services may not).
[1]: https://people.kernel.org/kees/colliding-with-the-sha-prefix...