Live data from Hacker News

Use GitHub actions at your own risk

julienrenaux.fr

51–60 of 65 posts

Re: Use GitHub actions at your own risk

#51

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…

Unlike git commit hashes, docker image tags can be overwritten by the maintainer at any time, even if they map to a hit commit hash.

Re: Use GitHub actions at your own risk

#52

The same could be said for any use of docker images. Seems a little unfair to single out Github.

Totally agreed. However, when do we stop making this mistake? I think it's worth a callout when a large organization designs a dependency management system with such an obvious flaw on the "happy path".

Re: Use GitHub actions at your own risk

#53

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

You seemed to take a pretty holistic, system-wide view of "critical path" which is fine. Do we know if the other person meant that?

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

#54
post #42

if you're going to use memes in a blog post at least use them correctly

What meme would you use then?

Instead of an incorrectly applied tapping head meme I would have used the Big Brain meme to sarcastically suggest that using a package’s reported version on the marketplace was smarter than a git SHA

Re: Use GitHub actions at your own risk

#55

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…

> Anything you use in a critical path you should control.

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

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

Yes. That is, you check in the binaries.

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

#58

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…

Welcome to a world were engineers aren't paid to copy code from Stack Overflow, but to make actual judgment calls.

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

#59

How does this different from any other hosted CI/CD solution? I am thinking specifically about: * Gitlab's CI * CircleCI * TeamCity etc....

I think the main difference is actions is built around the idea of this ecosystem of "just include other people's code in your pipeline." With Team City or GitLab you're typically only running code you wrote in their respective configuration files.

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

#60

Earlier 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.

Yes, they are popular. But on-premises ones also exist, are popular too, and mostly do not have this one problem.

It's a relevant distinction on this context.

Post reply on HN