Yet another Hacker News

65 points gslin 1 hour ago 12 comments

Already__Taken 1 hour ago | parent

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.

IMO Github should make Immutable tags mandatory to publish on https://github.com/marketplace

woodruffw 1 hour ago | parent

Actions lockfiles prevent this. They won't allow you to lock an impostor commit, which is the right default.

(The previous way to provide general actions immutability, i.e. hash-pinning, had this issue and thus required additional checks.)

OptionOfT 39 minutes ago | parent

One could write an action that executes a shell script that does docker pull abc:latest.

As the consumer of an action that becomes really hard to find out unless I take the whole codebase apart.

chrisweekly 19 minutes ago | parent

I almost forgot about that completely outrageous treatment of forks -- just bonkers.

SchemaLoad 1 hour ago | parent

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.

ezekg 1 hour ago | parent

Does this prevent one of the locked dependencies not locking their own dependencies and pulling in a malicious and replaced tag?

eddythompson80 1 hour ago | parent

It does not. Obviously if you lock a “foo/setup-latest-go” action, it’s still going to (and you’d probably expect it to) pull in the latest go. Actions are expected to start running though. Like GitHub isn’t gonna do an `npm install` for you, it’ll just run the entry point of the action, and the entry point can do whatever it was written to do.

woodruffw 1 hour ago | parent

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.

lukasschwab 48 minutes ago | parent

Are there clear reasons to prefer this over just pinning a commit SHA?

aleaph 28 minutes ago | parent

So "SHA pinning with version reference in a comment" with extra steps, got it

OptionOfT 20 minutes ago | parent

Enforced through GitHub Actions that is :)

gbraad 23 minutes ago | parent

I undrrstand this looks cleaner and more intuitive, but you still have the risk of running a workflow with malicious/compromised actions, like manually, or locally with act, if you do not verify the lockfile as part of the workflow or preceded by an extra workflow step. This should be something that the runner ideally should handle (as part of the platform). This still is a workaround, just like the sha pinning. I only use vendor upstream actions, like github's or forks in our own org.