[safaci2000]

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 library you were relying one has disappeared.

Anything you use in a critical path you should control. If you're managing your own fork, nobody will inject bad code except yourself.

Just my 2 cents. Also, the things that github 3rd party actions are doing is usually not that complicated. I mean how many different ways can you publish a docker image or deploy an artifact to S3. Once it works, it either works or doesn't. It's not a programming library where optimizations are created or we fixed a security vulnerability (though I suppose that can come up ).

Sorry minor rant. food for thought.

[harikb]

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 easy for those tools to provide upgrade/update path.

[goerz]

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

[btown]

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 :)

[xeromal]

Do you fork your own programming languages too?

[npo9]

We definitely standardize runtime and compiler versions across runtime environments and build servers and have planned upgrade paths with rollback options.

[jen20]

Not so much a fork as a package cache - but usually for anything important, absolutely.

[groby_b]

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)

[amdelamar]

Should fork the OS its running on too! /s

[xeromal]

Most def otherwise bad patches might ruin their production

[shaki-dora]

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.

[groby_b]

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

[acrispino]

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.

[savanaly]

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

[acrispino]

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.

[xamuel]

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.

[enraged_camel]

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

[mbesto]

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

[sneak]

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.

[larsla]

You can address image layers by sha256 hash. Do a docker pull of the image and the log will tell you the hash. Then you can do docker pull myimage@sha256:abc123def456...... I usually use these in my deployments since they can't be modified, it will require a new deploy.

[awintr]

came here to say this.