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…
Use GitHub actions at your own risk
41–50 of 65 posts
Re: Use GitHub actions at your own risk
#42if you're going to use memes in a blog post at least use them correctly
Re: Use GitHub actions at your own risk
#43Earlier 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)
Re: Use GitHub actions at your own risk
#44My 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…
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
#45My 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…
Re: Use GitHub actions at your own risk
#46This 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…
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
#47This 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?
Re: Use GitHub actions at your own risk
#48Re: Use GitHub actions at your own risk
#49> 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…
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
#50Earlier 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.