Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Actions is the weakest link

nesbitt.io

Post reply on HN
Print view View original

41–50 of 95 posts

Re: GitHub Actions is the weakest link

#41

Post by a_t48 »

suryao wrote: post #39
a_t48 wrote: post #24

Earlier quoted context omitted.

Why warpbuild over the alternatives? I've seen depot before and am tempted, but open to other platforms.

Founder of WarpBuild here. We have faster compute: baremetal for amd64 workloads, AWS for arm64 etc. We optimize for overall performance in real world jobs and have a broad selection of regions/OSes/arch available. There aren't any fixed subscription fees either.

Thanks for replying. Just a heads up https://www.warpbuild.com/compare/depot spins and doesn't show anything for me.

Re: GitHub Actions is the weakest link

#42

Post by pydry »

recursivedoubts wrote: post #10

Programming in YAML has always seemed crazy to me. Actions seem like a great place to create a simple mixed imperative/declarative scripting language (js extension or whatever) with a solid instrumented/observable/debuggable runtime and an OO API that can be run locally against mock infrastructure.

The YAML is way less concerning than the lack of any decent tooling to test and debug the code.

Re: GitHub Actions is the weakest link

#43

Post by suryao »

a_t48 wrote: post #41
suryao wrote: post #39

Earlier quoted context omitted.

Founder of WarpBuild here. We have faster compute: baremetal for amd64 workloads, AWS for arm64 etc. We optimize for overall performance in real world jobs and have a broad selection of regions/OSes/arch available. There aren't any fixed subscription fees either.

Thanks for replying. Just a heads up https://www.warpbuild.com/compare/depot spins and doesn't show anything for me.

Ack. Will take a look.

Re: GitHub Actions is the weakest link

#44

Post by octorian »

I'm personally not a fan of GitHub actions, because of those dependencies outside your control and more because they're a pain to debug. A lot of the time, it feels like I'm tinkering with this huge script then holding my breath and hoping I got it right.

The reason I use them, however, is because its more trouble than its worth to maintain build servers for the 3 platforms I care about (Windows, macOS, Linux) myself. Especially for projects that get built sporadically. I think one reason for this pain is that while you can easily run VMs for Windows and Linux on the same host, macOS is kinda its own special unicorn and might need a dedicated box. (But even that aside, maintaining machines you don't use every day can get annoying.)

Re: GitHub Actions is the weakest link

#45

Post by renegade-otter »

pydry wrote: post #42
recursivedoubts wrote: post #10

Programming in YAML has always seemed crazy to me. Actions seem like a great place to create a simple mixed imperative/declarative scripting language (js extension or whatever) with a solid instrumented/observable/debuggable runtime and an OO API that can be run locally against mock infrastructure.

The YAML is way less concerning than the lack of any decent tooling to test and debug the code.

When GHA were dead simple, there were projects simulating it locally. It's not possible anymore, and one had to burn a tens of hours just to develop the pipeline.

Re: GitHub Actions is the weakest link

#46

Post by 60secs »

pull_request_target is criminally negligent -- github should simply disable it.

The security risk for running unvalidated code on any random PR with access to account secrets has no legitimate use case which outweighs its unbounded risk.

Re: GitHub Actions is the weakest link

#47

Post by nulltrace »

ossianericson wrote: post #30

The OIDC federation between the runner and the cloud resources it touches , that credential gets created once. Permissive enough to not block the first deploy, and it is not what is reviewed when a pinning incident happens. Every one is looking at the action. The identity it runs as just sits there.

Common mistake is trusting the repo instead of the workflow. Then any workflow inherits the same cloud access.

Re: GitHub Actions is the weakest link

#48

Post by kbolino »

samuelknight wrote: post #7
rmunn wrote: 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'…

There is no realistic risk of a SHA collision attack. Getting supply chain attacked via NPM dependencies is much more likely. Hopefully the actions creators are also pinning their hashes.

> There is no realistic risk of a SHA collision attack.

Indeed. To illustrate why:

1. It is not possible to "retroactively" find a SHA-1 collision for an already known hash. If somebody has produced a SHA-1 hash non-maliciously at any point in the past, it is safe from collisions. This is due to second-preimage resistance, which hasn't been broken for SHA-1 and doesn't seem likely to be broken any time soon.

2. The only way to obtain a SHA-1 collision is to do so knowingly when producing the original hash. You generate a pair of inputs at the same time that both hash to the same value. Certainly, this is an imaginable scenario; e.g. a trusted committer could push one half of the pair wittingly or a reviewer could be fooled into accepting one half of the pair unwittingly, both scenarios creating a timebomb where the malicious actor swaps the commit to the second half of the pair (which presumably carries a malicious payload) later. However, there are two blockers to this approach: Git (not just GitHub) will not accept a commit with a duplicate hash, always sticking with the original one, and GitHub specifically has implemented signature detection for the known SHA-1 collision-generating methods and will reject both halves of such a pair.

In short, there's just no practical way to exploit this weakness of SHA-1 with Git.

Re: GitHub Actions is the weakest link

#49

Post by mmarian »

AlecBG wrote: post #25
rmunn wrote: 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'…

You can enforce at the org level to only allow actions pinned to hashes. You can also choose a small whitelist of actions to allow.

I used to think whitelist could be a partial solution. But after Checkmarx KICS got compromised I can't see this working. I would've considered a well-established brand, in security industry of all places, to be in the whitelist.

Re: GitHub Actions is the weakest link

#50

Post by sureglymop »

shykes wrote: post #36
sureglymop wrote: post #23

Earlier quoted context omitted.

Looks cool. Can it be self hosted? I.e. can I self host it next to my self hosted forgejo instance?

Yes, the Dagger engine is open source. Note that the engine on its own is not a CI replacement: it provides a runtime for your pipelines, but you still need an external system to trigger pipelines from git events. This decoupling is intentional, because CI should not be tightly coupled to git events . Sometimes you want to run a pipeline after pushing; but sometimes you need it before pushing, or even before committi…

Well, I'm sold! Trying out your offering this weekend :)
Post reply on HN