I see that updates could break CI and pinning to commits works. But what is the actual risk, considering that the CI jobs don't have any write permissions? That they could be used as part of a botnet and waste resources?

@karlb the attack would be replacing the action's own code with something malicious and making the moving Git tag point to it. The tag name would be the same, the commit hash would not unless you assume SHA1 broken. CI permissions do (or at least did) include write access unless you switched defaults on the repository(, and the default can be bypassed by the yaml file content, which is... not ideal).

This is probably not the repository at most risk, I just ran through all my local clones where this vulnerability was a theoretical possibility and made pull requests. I believe it is 100% step forward and 0% backwards personally, but if I'm missing some aspect, please let me know.

PS: Related tool https://app.stepsecurity.io/secureworkflow/ could also be of interest in this very context.

You might lose out on fixes and optimizations of newer versions, but that is a really minor downside.

@karlb I just re-checked, GitHub Dependabot already has us covered on that front via https://github.com/karlb/wikdict-web/blob/master/.github/dependabot.yml .