Live data from Hacker News

Use GitHub actions at your own risk

julienrenaux.fr

41–50 of 65 posts

Re: Use GitHub actions at your own risk

#41

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…

In addition to the security aspect, it would be really great if you have the option to lock down or cache the Docker images used for actions. It was weird for me when I pulled in an action from the marketplace for a workflow, and now about 80% of my total build time is building of that action for each and every build I run (e.g. the Dockerfile is compiled for that action EVERY time I run my build). I should have the option to at least cache that built image for me after the first time I run a workflow.

Re: Use GitHub actions at your own risk

#43
post #29
post #25

Earlier quoted context omitted.

While I understand the "fork everything you use" policy, github should make this process easier. Even though it is "free", it pollutes one's account/profile with hundreds of packages that are not really 'forks' with independent or alternate functionality. Many automated vendor/package management tools will not automate pulling newer changes from upstream. If this was instead a simple a read-only version/tag, it is ea…

A reasonably good solution to mitigate the “profile pollution” is to create a Github organization for these kinds of forks (I use -forks)

As a side effect this adds more organization icons to your Github profile, making it appear as if you're such an important OSS contributor that you're an official member of the Username Forks Alliance :)

Re: Use GitHub actions at your own risk

#44
post #38

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 packag…

This is an excellent point, and should solve the issue I put below about builds taking forever when pulling in a slow-building action.

If I'm using a marketplace action in my workflow, I want "foo/action@v1.0.0" to be treated like a binary package dependency, not a build from sourcecode.

Re: Use GitHub actions at your own risk

#45
post #38

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 packag…

All great points and I think you're onto something with the idea of using GitHub Packages. Definitely something we're considering, stay tuned.

Re: Use GitHub actions at your own risk

#46

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…

The lack of a bright line doesn't make the idea meaningless. It's just a judgement call.

It's not unreasonable to be more concerned about an open source library disappearing than say, postgresql or mysql disappearing. No macho posturing required.

Re: Use GitHub actions at your own risk

#47
post #21

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…

Do you fork your own programming languages too?

Should fork the OS its running on too! /s

Re: Use GitHub actions at your own risk

#49
post #16

> 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?

There are collision attacks against SHA-1. But the currently known collision attacks aren't a big problem for git for a variety of reasons. Git uses hashes that include more data than just the hash of the content of an object. Meaning the existing known collisions don't work and you'd have to develop collisions specifically to target git. Additionally, the current known collision attacks require generating the two co…

You hand-wave the difference between collision resistance and second-preimage resistance most away...

Just a recap: generating two files who's hashes collide takes 2^80 tries if SHA-1 wasn't broken, whereas finding a file with the same hash as a specific, externally-determined file takes 2^160 tries.

Re: Use GitHub actions at your own risk

#50

Earlier quoted context omitted.

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…

The lack of a bright line doesn't make the idea meaningless. It's just a judgement call. It's not unreasonable to be more concerned about an open source library disappearing than say, postgresql or mysql disappearing. No macho posturing required.

But people who complain about this stuff usually don't frame it that way-- absolutist statements like from the GP: "Anything you use in a critical path you should control." are common. The message is typically "I realize something fundamental that you don't and I'm owning all my dependencies and you don't own any of yours," rarely "I made a different choice about dependency ownership and here are the reasons I think that's appropriate for you too."
Post reply on HN