upvote

points

by imglorp7 hours ago |
comments
upvoteby lijok7 hours ago|
next
[-]
The problem is actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 probably doesn’t do this same pinning, and the actions ecosystem is such an intertwined mess that any single compromised action can propagate to the rest
reply
upvoteby imglorp7 hours ago|
parent|
next
[-]
Yes, true, but at least the fire won't spread through this one point. Hopefully all of your upstreams can be persuaded to pin also.
reply
upvoteby franktankbank5 hours ago|
parent|
[-]
Doesn't a single compromised action in the chain cause the whole to be fucked? Pinning the top level doesn't prevent any spread.
reply
upvoteby teaearlgraycold4 minutes ago|
parent|
[-]
Might want to vendor everything?
reply
upvoteby derfniw7 hours ago|
parent|
prev|
[-]
Well, it is a git commit hash of the action repo that contains the transpiled/bundled javascript.

Like: https://github.com/actions/checkout/tree/11bd71901bbe5b1630c...

So I'm pretty sure that for the same commit hash, I'll be executing the same content.

reply
upvoteby hobofan7 hours ago|
parent|
[-]
This is true specifically for actions/checkout, but composite actions can have other actions as dependencies, and unless the composite action pins the versions of its dependencies, it is vulnerable for this attack.

This article[0] gives a good overview of the challenges, and also has a link to a concrete attack where this was exploited.

[0]: https://nesbitt.io/2025/12/06/github-actions-package-manager...

reply
upvoteby rtaylorgarlock7 hours ago|
prev|
next
[-]
My preferred tool to solve these issues is called 'gitlab'
reply
upvoteby saxonww1 hours ago|
parent|
next
[-]
Does it solve anything? I don't see this as a GitHub problem, it's a "we built a dependency management system with untrusted publishers" problem.

GitLab's `include` feature has the same concern. They do offer an integrity check, but it's not any more capable than hash pinning to a commit.

Fundamentally, if you offer a way to extend your product with externally-provided components, and you can't control the external publishers, then you've left the door open to 'these issues'.

reply
upvoteby righthand7 hours ago|
parent|
prev|
[-]
CircleCI

TravisCI

Jenkins

scripts dir

Etc

reply
upvoteby b00ty4breakfast6 hours ago|
parent|
[-]
yeah, github's business model is not really a git repository but a bunch of other (admittedly useful) stuff that traps people in their ecosystem.
reply
upvoteby woodruffw7 hours ago|
prev|
next
[-]
See also pinact[1], gha-update[2], and zizmor's unpinned-uses[3].

The main desiderata with these kinds of action pinning tools is that they (1) leave a tag comment, (2) leave that comment in a format that Dependabot and/or Renovate understands for bumping purposes, and (3) actually put the full tag in the comment, rather than the cutesy short tag that GitHub encourages people to make mutable (v4.x.y instead of v4).

[1]: https://github.com/suzuki-shunsuke/pinact

[2]: https://github.com/davidism/gha-update

[3]: https://docs.zizmor.sh/audits/#unpinned-uses

reply
upvoteby kanzure7 hours ago|
prev|
next
[-]
I've always been worried about their backend changing and somehow named tags with a previous commit hash working for an attacker to give something you didn't expect for the commit hash.
reply
upvoteby OJFord4 hours ago|
prev|
next
[-]
> There is a tool to sweep through your repo and automate this: [third-party]

Dependabot, too.

reply
upvoteby silverwind4 hours ago|
prev|
next
[-]
This won't pin the action's dependencies, so it's a shallow approach only.
reply
upvoteby stefan_4 hours ago|
prev|
[-]
Checkout v4 of course, released in August 2025, which already now pollutes my CI status with garbage warnings about some Node version being deprecated I could absolutely care less about. I swear half the problems of GitHub are because half that organization has some braindead obsession with upgrading everything everywhere all the time, delivering such great early slop experiments as "dependabot".
reply