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

Use GitHub actions at your own risk

julienrenaux.fr

Post reply on HN
Print view View original

31–40 of 65 posts

Re: Use GitHub actions at your own risk

#31

Post by shaki-dora »

safaci2000 wrote: post #7

This also applies to most library, docker (as mentioned) and basically anything you use that's 3rd party. I suppose it varies on your level of paranoia, though honestly if you rely on a github action in your production flow you should fork the project. Never mind doing something malicious, they could just as easily delete the entire repo and now your critical feature you needed to deliver are blocked because the libr…

That's the sort of tough-guy prepper-with-a-slide-rule speech that people (apparently) just can't get enough of. But does it mean anything?

There is no bright line delimitating what's on the "critical path" and what's not. Your servers? The electric grid? The datacenter? The backbone(s) it's connected to? The judicial system making contracts enforceable? NATO? Name any two that straddle the line, and anybody can come up with something in between them, because it's a continuum.

Re: Use GitHub actions at your own risk

#33

Post by miskander »

My team and I work on Actions at GitHub and I just wanted to stop by and add a bit more context. We definitely understand the concerns the article brings up and it's actually why we recommend in our documentation using SHA references when consuming third-party Actions. We also introduced the concept of verified Actions that extend an Organization's verification to Actions in the marketplace. We know there's more to do here to help prevent any malicious Actions and we're planning to continue to iterate. Thanks so much for the feedback and keep it coming.

Re: Use GitHub actions at your own risk

#34

Post by xamuel »

shaki-dora wrote: post #31
safaci2000 wrote: post #7

This also applies to most library, docker (as mentioned) and basically anything you use that's 3rd party. I suppose it varies on your level of paranoia, though honestly if you rely on a github action in your production flow you should fork the project. Never mind doing something malicious, they could just as easily delete the entire repo and now your critical feature you needed to deliver are blocked because the libr…

That's the sort of tough-guy prepper-with-a-slide-rule speech that people (apparently) just can't get enough of. But does it mean anything? There is no bright line delimitating what's on the "critical path" and what's not. Your servers? The electric grid? The datacenter? The backbone(s) it's connected to? The judicial system making contracts enforceable? NATO? Name any two that straddle the line, and anybody can come…

GitHub could completely disappear and it wouldn't cause mass societal chaos or the breakdown of civilization. Those other things you listed, if they disappeared, there's quite a good chance they would cause mass societal chaos or the breakdown of at least certain civilizations. If the judicial system suddenly disappears, I reckon we'll have other things to worry about besides how it affects our build-chains.

Re: Use GitHub actions at your own risk

#35

Post by wizzwizz4 »

hn_throwaway_99 wrote: post #30

I think GitHub is making it extremely easy to make this mistake by making the Actions Marketplace so easily accessible when you're editing a workflow in their UI. This is horrible design. They should at least point out the real consequences of pulling in these other actions and letting you fork right there. I mean, there is an action in the marketplace that runs git-crypt to decrypt your files. With this issue, no us…

It's to reduce the friction to lock-in. GitHub should Just Work™, regardless if that sacrifices security, because the smoother the experience the more processes you'll build around it, so the harder it'll be to migrate away from it.

Re: Use GitHub actions at your own risk

#36

Post by mehrdadn »

polymeris wrote: post #6

> Each hash is supposed to be unique and you cannot rewrite history with the exact same SHA-1. I thought SHA-1 wasn't considered secure?

Depends on what attacks are relevant for your application. Even MD5 is still secure for some use cases. https://security.stackexchange.com/a/19908

Re: Use GitHub actions at your own risk

#37

Post by eximius »

miskander wrote: post #33

My team and I work on Actions at GitHub and I just wanted to stop by and add a bit more context. We definitely understand the concerns the article brings up and it's actually why we recommend in our documentation using SHA references when consuming third-party Actions. We also introduced the concept of verified Actions that extend an Organization's verification to Actions in the marketplace. We know there's more to d…

It sounds like you should add an abstraction layer that makes the default depending on the SHA. Your product should be secure by default and it clearly is not right now.

Likely, you can still do this and migrate people fairly painlessly to a secure version.

Edit: even if you select a tag or something, it should use the underlying reference instead of the tag. You can add an escape hatch if you REALLY want to target the tag (there are obviously workflows where that makes sense), but it should be off by default and warm users of the security risks.

Re: Use GitHub actions at your own risk

#38

Post by dherman »

miskander wrote: post #33

My team and I work on Actions at GitHub and I just wanted to stop by and add a bit more context. We definitely understand the concerns the article brings up and it's actually why we recommend in our documentation using SHA references when consuming third-party Actions. We also introduced the concept of verified Actions that extend an Organization's verification to Actions in the marketplace. We know there's more to d…

I’m excited about Actions generally, so I’m glad to hear your team is aware of the challenges of building a reliable ecosystem of third party dependencies by reference to repos.

Still, recommending git SHAs has real ergonomic and maintainability issues, and while it’s more defensive it doesn’t prevent left-pad style broken builds due to disappearing content.

And at the same time, GitHub is investing heavily in package management infrastructure. I don’t say this lightly because designing good dependency management systems is much more subtle and difficult than people typically recognize, but from where I sit this appears to be fundamentally a dependency management concern. It seems a shame not to try to put GitHub Package Registry to good work here. Is that something potentially on the horizon?

Re: Use GitHub actions at your own risk

#39

Post by enraged_camel »

shaki-dora wrote: post #31
safaci2000 wrote: post #7

This also applies to most library, docker (as mentioned) and basically anything you use that's 3rd party. I suppose it varies on your level of paranoia, though honestly if you rely on a github action in your production flow you should fork the project. Never mind doing something malicious, they could just as easily delete the entire repo and now your critical feature you needed to deliver are blocked because the libr…

That's the sort of tough-guy prepper-with-a-slide-rule speech that people (apparently) just can't get enough of. But does it mean anything? There is no bright line delimitating what's on the "critical path" and what's not. Your servers? The electric grid? The datacenter? The backbone(s) it's connected to? The judicial system making contracts enforceable? NATO? Name any two that straddle the line, and anybody can come…

Don’t forget payments, which are arguably the most critical part of any software that costs money.

Re: Use GitHub actions at your own risk

#40

Post by paco_sinbad »

What about hash collision? You could write an obfuscator to keep appending useless code or comments to the payload to continually generate commit hashes until you get a collision with the same original hash. A lot of work of course, and the hash is so f-ing huge it might take a few thousand compute-years, but you know, hackers find a way. If nothing else, use the full 40-char hash to ensure that your attacker has to find the same atom twice across 10 moons.
Post reply on HN