GitHub Actions Has a Package Manager, and It Might Be the Worst
76 points by soulcutter
76 points by soulcutter
It's worth noting that even if you pin everything, and even if you could pin transitive Actions references, the binaries they download might not themselves be pinned. You can do this in language package managers too, but that's considered a massive violation of expectations rather than standard practice.
I had never thought about this, but once-pointed-out, it does seem like a glaring omission how opaque action resolution is regarding version resolution. Clearly “it works”, I haven’t seen it exploited (is there any history there?), but like the author I’d feel a lot better if you could lock em
GitHub Actions have definitely been used as an attack vector (see this for example).
The canonical solution is to pin an action to a specific commit hash instead of using the 'naked' name or an @ version.
I guess that a workaround would be to write a small script that processes an unsecured workflow file and adds a pin to the actions to the correct commit hash. It would be kind of bundling the lock file within the workflow file itself.
a small script that processes an unsecured workflow file and adds a pin to the actions to the correct commit hash
That's pinact.
zizmor also checks (ref-version-mismatch) whether the tag comment after your hash-pinned action matches the hash. (pinact is able to verify + fix that mismatch as well.)
(At $job we set-up pinact + zizmor + actionlint as pre-commit hooks, and also run them as part of a "checks" CI workflow; works ok.)
The problem is real but comparing actions with language-specific package managers seems unfair.
Actions need to download and wrap many tools from many different languages and ecosystems, and in many cases the easiest way to download those is through arbitrary shell commands. It's hard to imagine a universal way to hash and lock all transitive dependencies without forcing the author to transitively package everything the same way one would do in e.g. Debian packages. Comparing actions to those seems more appropriate.
It's hard to imagine a universal way to hash and lock all transitive dependencies without forcing the author to transitively package everything
I think that’s how it should work
I do agree but then again have to remind myself that this is potentially the CI creating our next software release, with publish keys and distributing to millions of users. Not sure if I want that to be a shoddy system where everything goes.
This is a legitimate issue, except it is unlikely GitHub will fix this.
In the meantime, one should at least consider reducing the default broad permissions and eliminating GitHub token from persisting.
In my opinion, zizmor does a great job of enhancing the security posture of GitHub Actions.
I don't know if it's better or worse, but somehow everytime package managers are compared/analyzed, composer is never mentioned
Composer seems to be a language-specific package manager for installing PHP libraries. As untitaker wrote, language-specific package managers aren’t a fair comparison to GitHub Actions.
I think composer does fine. It has lock files at least and I've never seen it exhibit bad behaviour the few times I've used it