On the other hand, this issue has been known to GitHub since shortly after Actions’ release[0]. They added some cya verbiage to their docs, but they never followed up by making version pinning meaningful.

Sure you can implement it yourself for direct dependencies and decide to only use direct dependencies that also use commit sha pinning, but most users don’t even realize it’s a problem to begin with. The users who know often don’t bother to use shas anyway.

Or GitHub could spend a little engineer time on a feasible lock file solution.

I say this as somebody who actually likes GitHub Actions and maintains a couple of somewhat well-used actions in my free time. I use sha pinning in my composite actions and encourage users to do the same when using them, but when I look at public repos using my actions it’s probably 90% using @v1, 9% @v1.2 and 1% using commit shas.

[0] Actions was the first Microsoft-led project at GitHub — from before the acquisition was even announced. It was a sign of things to come that something as basic as this was either not understood or swept under the rug to hit a deadline.

> it doesn't work for transitive deps unless those are specified by SHA as well, which is out of your control

So in other words the strategy in the docs doesn't actually address the issue

- Using the commit SHA of a released action version is the safest for stability and security.

This is not true for stability in practice: the action often depends on a specific Node version (which may not be supported by the runner at some point) and/or a versioned API that becomes unsupported. I've had better luck with @main.

Using an SHA is an anti-pattern for me. Because by using one, you kind of modeled "I am getting this fixed/static thing"; when in reality, it is very far from that. I got bitten by it twice that I learned that you either have a lock file or you don't.

> Their entire ecosystem is basically held up with duct tape and gets very little investment.

That isn't gonna get better anytime soon.

"GitHub Will Prioritize Migrating to Azure Over Feature Development" [1]

[1] https://thenewstack.io/github-will-prioritize-migrating-to-a...

An interesting things is that GitHub is an expensive service and my guess would be that MS makes good money on it. Our small company paid about 200+ USD monthly for GitHub, much larger cumulative cost than Windows licenses. My believe was that Windows is getting worse, because it is considered legacy business by MS in favor of new offerings such as GitHub subscriptions.

The quality of setup-* actions has definitely gone down and there are a lot of strange decisions being made. I assume the original authors of these actions have long left the company.

This is the first time I've heard of this, do you happen to have an example?

Didn't they announce to slow down development for AI?

you just described every microsoft business model.

That issue with their own small private forks has actually raised its head while testing out the AI slop generator thing it has, making anything it produces for you not self hoatable unless you rewrite a lot of basic functions. Sweet irony.

Which is strange because they have infinite Microsoft money and can print more if they get it into enterprises.

(we run a private gitlab instance and a merge request can spawn hundreds of jobs, that's a lot of potential Gitlab credits)

With AI you won't need CI anymore, it's all going straight to prod anyway /s

Actions is one thing, but after all these years where the new finegrained access tokens aren't still supported across all the product endpoints (and the wack granularity) is more telling about their lack of investment in maintenance.

I never used any actions and never understood why would I need to. I just wrote bash script to build my project and that's about it. This modern tendency to add dependencies for trivial things baffles me. You don't need "action" to do `git clone`.

Everyone is free to use alternative CI/CD workflow pipelines. These are often better than Github Actions.

These include

- https://circleci.com/

- https://www.travis-ci.com/

- Gitlab

Open source:

- https://concourse-ci.org/ (discussed in the context of Radicle here https://news.ycombinator.com/item?id=44658820 )

- Jenkins

-etc.

Anyone can complain as much as they want, but unless they put the money where their mouth is, it's just noise from lazy people.

It's funny that absolutely everything about GHA fucking sucks, and everyone agrees about this. BUT, the fact that it's free compute, and it's "right there"... means it's very very difficult to say no to!

Personally I've just retired a laptop and I'm planning to turn it into a little home server. I think I'm gonna try spinning up Woodpecker on there, I'm curious to see what a CI system people don't hate is like to live with!

> there’s a whole generation of young engineers who don’t know how short their end of the stick actually is

I'm from a generation who had to use VSS for a few years. The sticks are pretty long these days, even the ones you get from github.

I'm accustomed to just doing as much as possible locally. GHA doesn't even seem like a value-add over that for me.

Hosted code on GitHub no less

> I would argue that a good CI/CD system should not support secrets as a first-class object at all. Instead steps may have privileges assigned. At most there should be an adapter, secure enclave style, that may hold a secret and give CI/CD steps the ability to do something with that secret, to be used for APIs that don’t support OIDC or some other mechanism to avoid secrets entirely.

This all seems right, but the reality is that people will put secrets into CI/CD, and so the platform should provide an at least passably secure mechanism for them.

(A key example being open source: people want to publish from CI, and they’re not going to set up additional infrastructure when the point of using third-party CI is to avoid that setup.)

“Good CI systems shouldn’t support secrets, at most there should be [the most complicated secret support ever]”

Let’s just call it secret support.

I agree with your suggestion that capabilities-based APIs are better, but CI/CD needs to meet customers where they’re at currently, not where they should be. Most customers need secrets.

We use proprietary tools (QNX compiler, Coverity static analysis, ...) and those require access to a license server which requires some secret.

I don't really understand what you mean by "secure enclave style"? How would that be different?

> I would argue that a good CI/CD system should not support secrets as a first-class object at all. Instead steps may have privileges assigned. At most there should be an adapter, secure enclave style, that may hold a secret and give CI/CD steps the ability to do something with that secret, to be used for APIs that don’t support OIDC or some other mechanism to avoid secrets entirely.

CI/CD does not exist in the vacuum. If you had CI/CD entirely integrated with the rest of the infrastructure it might be possible to do say an app deploy without passing creds to user code (say have the platform APIs that it can call to do the deployment instead of typical "install the client, get the creds, run k8s/ssh/whatever else needed for deploy").

But that's a high level of integration that's very environment specific, and without all that many positives (so what you don't need creds, you still have permission to do a lot of mess if it gets hijacked), and a lot, lot more code to write vs "run a container and pass it some env vars" that had become a standard

How do you e.g. validate that a database product works with all the different cloud databases? Every time you change up SQL generation you're going to want to make sure the SQL parses and evaluates as expected on all supported platforms.

Those tests will need creds to access third party database endpoints.

You're missing that the D in CI/CD means deployment; be that packaging on pushing tags and publishing to a registry, or building images, or packaging github releases.

CI is arguable, but how do you intend to do deployments with no secrets?

> But there is absolutely nothing about calling an API that fundamentally requires that the caller know a secret.

There is if you pay for API access, surely?

While good in theory, in practice secrets are used to validate those privileges have been assigned. Even in schemes like metadata servers, you still use a secret.

Pedantically I'd say maybe it's more fair to say they shouldn't have access to long lived secrets and should only use short lived values.

The "I" stands for Integration so it's inevitable CI needs to talk to multiple things--at the very least a git repo which most cases requires a secret to pull.

> Why do CI/CD systems need access to secrets?

Because you need to be able to sign/notarize with private keys and deploy to cloud environments. Both of these require secrets known to the runner.

Because for some reason they use the same system to do releases and sign them and publish them.

You might want (or _need_) to sign your binary, for example. Or you might want to trigger a deployment.

Github actually is doing something right here. You can set it up as a trusted identity provider in AWS, and then use Github to assume a role in your AWS account. And from there, you can get access to credentials stored in Secret Manager or SSM.

TFA mentions this option and then goes on at some length to explain that this doesn't help for transitive dependencies, which is how these attacks usually work.

Transitive dependencies?

renovatebot and dependabot can take care of that. Setting up CI is progress, nothing to regret.

And if not mise, just a Makefile, shell scripts or custom docker images. Then you can run and develop them locally.

GitHub actions has some rough edges around caching, but all the packaging is totally unimportant and best avoided.

This right here - I am migrating all of our GHA to use the mise action. Makes keeping the version of Go, linters, formatters etc. for the project so much easier. Haven't added the mise.lock yet, but on the list. Now getting my small team of devs to try using mise is much harder.

Dagger does what you're describing: https://dagger.io/

> I've not understood the propensity for using yaml for CI pipelines and workflows in general. A decent programming language would be a big improvement.

Because it's clear to write and read. You don't want your CI/CD logic to end up being spaghetti because a super ninja engineer decided they can do crazy stuff just because they can. Same reason why it's a bad idea to create your infrastructure directly in a programming language (unless creating infrastructure is a core part of your software).

> Why not just build the workflows themselves as docker images? I guess running other docker images in the workflow would then become a problem.

That's how Drone CI handled it. GitLab kind of does the same, where you always start as a docker image, and thus if you have a custom one with an entrypoint, it does whatever you need it to.

it's wild I can wiz through a ton of code for hours on end but seeing a yaml file for something like a CI pipeline actually makes my brain eject i dunno why. my brain has some sort of proverbial capacity limit with how many different configuration-file looking things I can tolerate in a day, and the prospect of becoming intimately familiar with what is effectively an auto integration presented to me as some sort of config makes me completely unjustifiably butthurt for no reason. have i not suffered enough needless and often times limiting abstractions already

On the plus side, Forgejo Action's implementation is still actively improving, where it seems that for GitHub if it's not AI, it's not being touched.

However, as noted in the article, Forgejo's implementation currently has all the same "package manager" problems.

Do you have a write up about this? Actions are great, but my #2 gripe with actions, after the tenuous security posture, is that the default practice is not to run/validate actions locally.

I would recommend you to try uv for this.

You don't, but that's the wrong question. How do you know they're accurate?

I’d say that GitHub has done an admirable job making attestations more accessible, but that “easy” is still a stretch of a characterization: it’s still not the default, and the error/configuration states are somewhat opaque (e.g. around OIDC permissions, unprivileged triggers, what constitutes a signing identity in a reusable workflow context, etc.). Some of these are latent complexities that GitHub can’t be blamed for, but some are certainly made worse by architectural decisions in GitHub Actions.

You specifying the top level hash doesn't do anything to pin transitive dependencies, and as the article points out, transitive dependencies - especially dependencies common to a lot of actions - would be the juciest target for a supply chain attack.

> which I'm aware may not be the same if the tag was updated.

That's the mistake that breaks the following. People don't usually expect that it's an arbitrary modifiable reference, but instead that it's the same version they've picked when they created the file (ie a tag is just a human friendly name for a commit)