Hacker News new | ask | show | jobs
by wutwutwat 468 days ago
You can target `some/action@commithash` already, that's up to you. You're also free to fork or clone each action you use, vet the code, and consume your fork in your workflows. You can also disable the use of third party actions at an org level, or approve them on a case-by-case basis.

This all depends on your threat model and risk tolerance, it's not so much a GitHub problem. There will always be bad code that exists, especially on the largest open source code hosting platform. You defend against it because that's more realistic than trying to eradicate it.
2 comments
chuckadams 467 days ago
Someone elsewhere suggested a lockfile, which seems a pretty obvious solution in hindsight. I'm fine with commit hashes, but the UX is terrible and consists of pasting the action into into StepSecurity's thingie, when this is something that GH should have built in.
link
wutwutwat 467 days ago
> Someone elsewhere suggested a lockfile

commit hashes are immutable, and your own commit history can serve as the lock file.

but if you're targeting a commit hash directly, it's already locked. Lock files are for mapping a version range to a real life version number. Lock files are useless if you pin the exact version for everything.

link
chuckadams 467 days ago
Sure, it's just that the DX of getting that commit hash isn't terrific, so one might be more inclined to trust an auto-update bot to automatically update them instead. A lock file is more like TOFU on a tag. I'd also take a UI like a "bake" button and CLI flag that substituted the hashes automatically, but you just know people are going to build `--bake` right in to their automation.

Another solution would be to implement immutable tags in git itself, but git upstream has so far been hostile to the whole concept of immutability in any part of git.

link
arianvanp 468 days ago
One problem with this is that actions can be Composite and call arbitrary other actions. So only if you use actions that themselves lock everything by commit for the actions they depend on you're safe.
link
wutwutwat 467 days ago
You just described a supply chain, and the risks that come with them, which is something every dep management system is dealing with, rubygems, npm, etc

Again, it all comes down to your risk tolerance. There's a certain level of trust built into these systems.

link