[ckastner]

It is different. While it is obviously true that I haven't checked all of the binaries I'm running, I at least can, through the various signatures involved, rely on the fact that it was created by a particular individual or group, whom I may trust.

Would you really assign the same level of trust to, eg, a sudo(8) binary downloaded somewhere of the internet as you would to the one provided by your distribution?

[nothrabannosir]

That's not the comparison being made. It's between piping curl to bash, or just downloading a script and running it with sudo, without inspecting.

Yes, you "could inspect". But this is about the instructions. And instructions to pipe curl to bash are no more or less harmful than instructions to download a binary from a "random" server and run it verbatim.

"Piping curl to bash" is a red herring. It's "running unverified code" that's the problem. Piping curl to bash just makes it viscerally obvious how dangerous that is.

[mseebach]

There are various levels of trust, of course. The packages in Debian or RedHat are more trustworthy (there is a process) than those in NPM or Maven (free-for-all, even if you have some assurance that the package you're downloading is the very same the developer uploaded).

But installing a random NPM package is no more dangerous than curl-piping a script from Github to bash over HTTPS (without -k). You're still sure that what you're downloading and running is what whoever is in control of that repo intended.

What IS more dangerous is training a generation of developers to solve problems by quickly copy-pasting random strangers' magic incantations from random blogs or Stackoverflow into their terminals. You could probably infect a large number of machines very quickly by stalking certain categories on Stackoverflow for "noob" questions and giving a good answer in the form of a GitHub gist curl-pipe to sudo that fixes the problem, but that also discreetly backdoors the target.