[mcintyre1994]

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?

[anamexis]

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?

[mcintyre1994]

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.

[anamexis]

No, I don't think Github blocks shortened commit SHAs as tags.

[chatmasta]

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.)

[auscompgeek]

> They can't block every 8 character tag.

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.