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…
Use GitHub actions at your own risk
51–60 of 65 posts
Re: Use GitHub actions at your own risk
#52The same could be said for any use of docker images. Seems a little unfair to single out Github.
Re: Use GitHub actions at your own risk
#53Earlier quoted context omitted.
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…
Let's say I'm working front-end web development. My "critical path" might include: js bundler, some kind of application framework, various libs, etc. The scope of my work (and authority/responsibility) informs what I can reasonably have under my control.
Re: Use GitHub actions at your own risk
#54if you're going to use memes in a blog post at least use them correctly
What meme would you use then?
Re: Use GitHub actions at your own risk
#55This 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…
https://en.wikipedia.org/wiki/Not_invented_here
?
> It's not a programming library where optimizations are created or we fixed a security vulnerability (though I suppose that can come up ).
But it's a service provided by a paid-for entity which has support which you pay for. If it doesn't work, you let support know....
Re: Use GitHub actions at your own risk
#56Re: Use GitHub actions at your own risk
#57This 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?
Do I do this for hobby projects? No, of course not. If my toy projects break, meh. But for production? Where breakage actually costs money? Damn right I do.
It's not only breakage, though. You want a hermetic build system, so you can build software reproducibly and consistently. There are few things more "fun" than building "the same" code on two machines, and one executable has a bug while the second doesn't. (OK. Compiler bugs are even more fun)
Re: Use GitHub actions at your own risk
#58This 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…
What's the chance of the grid going down? What's the cost of it? Is the expected value significantly higher than a power generator? Congrats, you just bought a power generator.
Backbone down would cause you huge financial losses? Well, whaddaya say, let's build more backbone.[1]
Any redundancy that costs significantly less than the losses it mitigates will be built. The only reason we're not seeing a private NATO yet is that it costs more than pretty much any company makes. But 5,000 people security forces? Damn skippy those exist[2]
[1] https://engineering.fb.com/data-center-engineering/building-... [2] https://www.businessinsider.com/facebook-off-duty-police-off...
Re: Use GitHub actions at your own risk
#59How does this different from any other hosted CI/CD solution? I am thinking specifically about: * Gitlab's CI * CircleCI * TeamCity etc....
That's super valuable because you get started faster - e.g. "oh here's how I can deploy a lambda" but brings up this security concern of running other people's code. As discussed in the article, this is something NPM solved after the left-pad debacle. And I am sure (I hope) that GitHub will either change the documentation or add features to prevent this.
Re: Use GitHub actions at your own risk
#60Earlier quoted context omitted.
This isn't much different than other SaaS CI/CD pipelines.
Right, such as travis, circleci, gitlab, etc. All of which are pretty popular, so clearly there is interest in SaaS CI/CD.
It's a relevant distinction on this context.