Whose code am I running in GitHub Actions?

Shortened commit SHAs are actually not supported by Actions; if you try, you get

"Unable to resolve action `actions/checkout@11bd719`, the provided ref `11bd719` is the shortened version of a commit SHA, which is not supported. Please use the full commit SHA `11bd71901bbe5b1630ceea73d27597364c9af683` instead."

So just so I'm clear based on what you've mentioned, even the policy prohibiting 40 hex character tags isn't doing anything to stop a tage the same as the short commit ID?

Also, per this comment on a previous discussion on this incident at https://news.ycombinator.com/item?id=43367987#43369710:

> the real renovate bot immediately took the exfiltration commit from the fake renovate bot and started auto-merging it (updating full SHA1 references)

Yes, this is a crucial distinction to make. The fact of the matter is that you have to treat GitHub Actions like a compromised system. Sure, there's not a ton of steps you can take for protecting builds if it's your primary builder, but you can for example not hook up an AWS account with full admin privileges to it (which I've seen more times than I would have like to).

https://github.com/features/preview/immutable-actions

They are actually releasing this very soon. I’ve seen some of my workflows use an immutable OCI image for some of GH’s actions like actions/checkout.

Isn't that wrong? I think you have to pre-bundle your actions, it won't do an npm install.

Thanks for highlighting this open issue.

The fact they've been stalling this for a good 2.5 years is... insane??

I don't believe that's true. If you pin to a hash, then it will always run that version and can't change

> major versions are intended to be mutable and be updated to point to new minor versions as they are released [...] because you "can expect an action's patch version to include necessary critical fixes and security patches [...]

It's two sides of the same coin: on one hand, an update can include fixes for bugs and vulnerabilities; on the other hand, an update can also include new bugs and vulnerabilities (or even malicious code). Updating too quickly can be risky. Updating too slowly can also be risky.

While this may be technically correct, the general git-community at large mostly treats tags as immutable (contrary to docker, for example).

Release branches are typically the mutable reference. So I would create a 'v2' release branch, but not a 'v2' tag which gets updated.

Also, by convention, git references starting with 'v' are typically immutable tags and not branches.

But, even given the above, the git-community at large knows that tags can be mutable, and so if we care about that, we reference the sha (malicious collisions excepted).

That wording is even more misleading, because it implies that using the full version string, by contrast, is not mutable, even though it presumably is.

> I ended up writing a driver program for my personal project’s CI builds. One job builds the driver program, and then the next job runs the driver program to do the entire build.

Yes things like that have been discussed before on HN. Also for example use a justfile (or something similar) and then call that from inside the Action to reduce vendor lock-in.

I use Actions merely as a way to trigger a custom Webhook. Then I do everything on the server that receives the hook with my own code. I hate YAML that much.

Do you mind linking the repo, if it's public? Thanks!

This seems like a wild thing for a third-party project to promote. The intention of GitHub Actions to run CI/CD and other repository-related tasks. You’d never see, for instance, Adobe promoting, via YouTube, “unlimited free web OCR with Adobe CLI on GitHub Actions!”

I’ve never heard of Seleniumbase, but this makes them look like a rinky-dink project.

I've found this to be a problem that a lot CI providers suffer from. They allow extension via third party code which is awesome, people write useful code, a lot of that useful code doesn't get maintained properly or ever, rots, and eventually everyone has a security issue.

You can also see the GitHub IP space here, I don't think it's "residential", unless that terminology includes azure and aws?: https://api.github.com/meta

They don't use a residential IP space; they use Azure Data Center (which, being less popular, isn't blocked as often as for example EC2).

Network enabled compute is definitely an unusual free lunch, but I suppose the trade off is handing out free source code.

This does not bode well for genetic AI

I agree on community ones, but I’m happy to use the official actions from vendors like the Terraform and Azure ones too.

This is probably the dumbest design decision of GitHub Actions. You'd think that the biggest git platform would know better than asking you to force push every release. They should have just used branches, because that's exactly what they're for. Or they should have resolved the right tag themselves, like npm does.

I only use a handful of official github and docker actions. This behavior is something that I (and many others) want in that case.

Here @v4 is very similar to how you'd tag docker image v4-latest.

Ultimately, it should be a choice. Like you can do with package.json. Pin an exact, allow patch updates, allow minor updates or always latest etc.

Oh. I always assumed that v2 here was a branch, not a moving tag.

Was this an auto-generated comment? Because yes, of course it's related, it's someone doing their own investigations based on the news.

My company went into full panic mode after this. 5 minutes later dependabot opens and auto merges a random patch from npm, but that's fine.

Most people use several hundreds millions of lines of code provided by somebody else on a daily basis (your laptop, your phone, your hair dryer, car, etc). Most of that stuff gets built using libraries, components, frameworks, etc. provided by third parties.

The whole system runs on trust that all those people do the right things. Sometimes that trust is broken. But mostly it's surprisingly fine. Part of the reason is that bad people are the exception and not the norm and all those other people react when we find one, some are mildly paranoid about this, and processes exist for flagging suspicious things (e.g. CVEs).

What we need is not to audit everything ourselves. Because that's humanly impossible. But better trust verification mechanisms and tools. Github has some mechanisms for actions but it still has some vulnerabilities. It's not perfect. But it's better than nothing. Replacing those by auditing/building yourself is going to either result in a lot of work or security with holes in it (i.e. you are moving the problem, not solving it).

You could argue that most GH Actions are simple enough that building yourself is not the end of the world. It depends on what you are doing.

I take the middleground. I use GH actions but only with widely used actions maintained by Github. Actions are just docker containers. So, the advice can be generalized to those. Check where they come from; who is building them; what their release practices are. Etc.

> just blindly paste together calls into GitHub actions written by someone else who can change it at any time?

That’s old news. Now they have the AI do it.

Before this article I had no idea this was even something you could do let alone something that's common.

Why would you not just copy the couple of lines in to your own config. It's not like you need to subscribe to updates on a command to get changed files. You want the exact opposite so your CI doesn't randomly break due to external changes.

Where to (just out of curiosity)?