Live data from Hacker News

GitHub Actions is the weakest link

nesbitt.io

81–90 of 95 posts

Re: GitHub Actions is the weakest link

#81
post #68
post #4

Back when GitHub Actions first came out, I used commit hashes rather than tags in all my `uses:` lines. Some of my colleagues disagreed, saying that tags were secure enough. I eventually said, "Well, for well-known actions like actions/checkout, sure; if that one gets compromised it'll be all over the news within minutes." But for all the third-party actions, I kept commit hashes. I feel rather vindicated now. There'…

Maybe it's better to pull that dependency source in your action altogether?

Better to treat it as a dependency still, but audit each new commit/release as it comes in, and pin to the exact last commit id that you verified.

Re: GitHub Actions is the weakest link

#82
post #14

I apologize in advance for the plug. I've spent the last 5 years warning of the importance of not leaving CI locked in a black box platform and proprietary DSL. All the while going on a quest to reinvent CI as an open, programmable platform. Honestly it's still a work-in-progress: it turns out that reinvention is hard! But, if you want a glimpse of what CI can be when you shed 30 years of legacy, consider checking ou…

Wow I've been struggling with deployment/CI on Claude/Codex/devcontainers for the last several weeks and this looks amazing. I'm trying to find a "universal" way to deploy on multiple cloud and baremetal platforms.

Re: GitHub Actions is the weakest link

#83
Github Actions is a decidedly unserious product, used largely by unserious people.

It's always been poo, the YAML is bad, the reliability is bad and the cost is bad.

So there is really no redeeming features because even if you tout forge integration it's UI is, you guessed it, also bad.

Putting aside the anti-pattern of using vendor YAML for literally anything (please don't do that) you are distinctly better off with literally any other CI/orchestration service. Buildkite is good, dynamic pipeline = good, there are other good options. If you are a serious person you will find good things to use.

Getting back to vendor YAML, please just use a real build system instead. Define all the actual logic there with entry points/targets the YAML hits. Also generally make sure that you don't need the actual CI system to be up to do releases, deployments etc. A sufficiently elevated local user should be able to run the appropriate target with the appropriate credentials to get the job done in absence of said CI system.

Re: GitHub Actions is the weakest link

#84
post #80
post #34

Earlier quoted context omitted.

If you auto merge those PRs you're back to square 1 as you're not vetting your dependency updates. And if you don't, you incur operational overhead unless you put in a fair amount of effort centralizing. Wrote a couple of posts that touched on this https://developerwithacat.com/blog/202604/github-actions-sup...

How many people actually audit the code changes in their dependencies when updating them?

Few, if any. Which is why I'm highlighting that you can't just use commit SHA + Renovate then call it a day.

Re: GitHub Actions is the weakest link

#85
post #79

Yup! Still haven't switched off of Github, but considering it at this point. If you're in my shoes, here's some tools we use that help: - https://github.com/sethvargo/ratchet for pinning external Actions/Workflows to specific commit hashes - https://www.warpbuild.com/ for much faster runners (also: runs-on/namespace/buildjet/blacksmith/depot/... take your pick) - soon moving to Buildkite for orchestration of our CI j…

VP at Buildkite here; let me know if you need anything as you begin to move over to us for orchestration. The new trial we just released unlocks everything in the platform, and we can extend past 30 days if you need.

Oh sweet, thanks Mitch! I was a customer of Buildkite a few years ago, looking forward to working together again.

Re: GitHub Actions is the weakest link

#87
post #37
post #12

Earlier quoted context omitted.

GitHub Actions doesn't have a lock file, so your repo is still prone to transitive attacks if the SHA-locked actions you use also happen to use other composite actions by tags, which could be compromised in the future.

Agreed. Good news is GitHub will address that with Immutable Releases https://github.blog/news-insights/product-news/whats-coming-... You won't even need to use commit SHA as long as the maintainer follows this approach.

The actions/checkout repo still doesn't even use immutable releases so I'll believe it when I see it

https://github.com/actions/checkout/issues/2316

Re: GitHub Actions is the weakest link

#88
post #37

Earlier quoted context omitted.

Agreed. Good news is GitHub will address that with Immutable Releases https://github.blog/news-insights/product-news/whats-coming-... You won't even need to use commit SHA as long as the maintainer follows this approach.

The actions/checkout repo still doesn't even use immutable releases so I'll believe it when I see it https://github.com/actions/checkout/issues/2316

Yes, it's maddening. Especially since it's a fair amount of effort to move to commit SHA pinning and establish a good maintenance/monitoring process around it; if I knew it would be adopted quickly, I could argue that people should just wait and accept temporary risk.

Re: GitHub Actions is the weakest link

#89
post #79

Earlier quoted context omitted.

VP at Buildkite here; let me know if you need anything as you begin to move over to us for orchestration. The new trial we just released unlocks everything in the platform, and we can extend past 30 days if you need.

Oh sweet, thanks Mitch! I was a customer of Buildkite a few years ago, looking forward to working together again.

Happy to help with whatever you need when the time is right!

Re: GitHub Actions is the weakest link

#90
post #81
post #68

Earlier quoted context omitted.

Maybe it's better to pull that dependency source in your action altogether?

Better to treat it as a dependency still, but audit each new commit/release as it comes in, and pin to the exact last commit id that you verified.

Yes, but no one audits new dependencies versions usually. Only Release Notes mostly.
Post reply on HN