3 ms·

I wish Github required some sort of immutability for actions by default as most package managers do, either by requiring reusable actions to be specified via co

I wish Github required some sort of immutability for actions by default as most package managers do, either by requiring reusable actions to be specified via commit hash or by preventing the code for a published tag to be changed. At the moment the convention is to only specify the tag, which is not only a security issue as we see here, but may also cause workflows to break if an action author updates the action.

wutwutwat 2y 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.
- deleted 2y ago
  [deleted]
- arianvanp 2y 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.
  - wutwutwat 2y 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.
- chuckadams 2y 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.
  - wutwutwat 2y 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.
    - chuckadams 2y 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.
mubou 2y ago
Someone else in the thread mentioned that this is coming! https://github.com/features/preview/immutable-actions https://github.com/features/preview/immutable-actions

wutwutwat 2y 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.

deleted 2y ago
[deleted]
arianvanp 2y 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.
- wutwutwat 2y 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.
chuckadams 2y 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.
- wutwutwat 2y 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.
  - chuckadams 2y 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.

mubou 2y ago

Someone else in the thread mentioned that this is coming! https://github.com/features/preview/immutable-actions https://github.com/features/preview/immutable-actions