Using a branch or tag version is a security risk

[diversit]

It seems the latest version enforces to use the 'v3' tag, failing even when the master commit tag.
For more info, read e.g. https://julienrenaux.fr/2019/12/20/github-actions-security-risk/

So please allow using commit hashes again to select a specific action version and update the documentation.

[joekelley]

FWIW I was able to use the commit SHA bd0b592a410983316a454e3d48444608f028ec8e, which is currently tagged as 3.1.0, as a version for this action in a private project without issue.

[dominics]

Not only that, but this check now breaks the strategy used by tools such as e.g. Renovate, to ensure actions are securely locked to a specific version rather than a mutable tag: https://github.com/renovatebot/renovate/blob/144178827959eee183b91f3f5c4b340b4271d45d/lib/manager/github-actions/readme.md

Edit: not true, see @TimonVS below, and just make sure any tool you're using that locks the ref to a SHA hash uses one that corresponds to a tagged release

[TimonVS]

Thanks for the feedback. The reason you can't use any commit SHA is because the code needs to be compiled first. The latest compiled version is available in the releases/v3 branch and the v3.1.0 tag. To pin to a specific version, you can use any SHA of a Git tag or from a commit in a releases/* branch.

@dominics I'm not entirely sure what you're referring to. Is there any action I can take to make sure this action can be properly updated by Renovate?

[dominics]

@TimonVS Sorry, I was thinking the assumption by OP was correct, and there were no fully-pinned (sha hash) revisions available for use. As commit hashes that correspond to tagged releases can be used, all that's left is for me to make Renovate use them in my own config (which is possible with a comment in the .yml) 👍