The advice here is really great (as I'd expect from Hugo), but as the maintainer of zizmor I want to note some caveats with the current iteration of workflow lockfiles:
- They only lock normal action calls. If your workflows invoke other reusable workflows, you need to keep those hash-pinned manually for now.
- Composite actions are not themselves locked. Instead, they get locked transitively through their callsites i.e. the workflows that call them. This makes any individual caller that uses lockfiles safe, but it also makes the current `gh actions-lock` default unsafe (since it removes hash-pins from the composite action itself, meaning that any external caller that invokes the action loses their transitive pinning).
- Other forms of `uses:` clauses, like Docker images, are also not currently locked via the lockfile. And the same for forms of interior mutability (like an action running `npx ...` under the hood, although the latter is fully outside of GitHub's control to prevent. But these mean that you can't assume that a fully locked Actions setup is in fact 100% immutable.
I hope they address these gaps soon, because it's otherwise an excellent (and long-awaited) feature.
woodruffw
Quoting someone else's blog I've forgotten but you're trading the trust in the repo owner not moving a tag for trusting whoever merges the commit hash to have checked that's a release in the repo you want and not _some_ forks commit. All forks on github are the same repo you can pin any commit, merged upstream or not.
Are there clear reasons to prefer this over just pinning a commit SHA?
lukasschwab
Are people finding a real need for importing and updating git actions? Aren't they usually just running a one line bash command? I'd just copy paste the action in to your config so it's fully locked and under your control rather than importing some opaque script from a no name github user.
SchemaLoad
Does this prevent one of the locked dependencies not locking their own dependencies and pulling in a malicious and replaced tag?
comments (5)
- They only lock normal action calls. If your workflows invoke other reusable workflows, you need to keep those hash-pinned manually for now.
- Composite actions are not themselves locked. Instead, they get locked transitively through their callsites i.e. the workflows that call them. This makes any individual caller that uses lockfiles safe, but it also makes the current `gh actions-lock` default unsafe (since it removes hash-pins from the composite action itself, meaning that any external caller that invokes the action loses their transitive pinning).
- Other forms of `uses:` clauses, like Docker images, are also not currently locked via the lockfile. And the same for forms of interior mutability (like an action running `npx ...` under the hood, although the latter is fully outside of GitHub's control to prevent. But these mean that you can't assume that a fully locked Actions setup is in fact 100% immutable.
I hope they address these gaps soon, because it's otherwise an excellent (and long-awaited) feature.
woodruffw
IMO Github should make Immutable tags mandatory to publish on https://github.com/marketplace
Already__Taken
lukasschwab
SchemaLoad
ezekg