Xjyuk

The most straightforward way to install NodeJS on Ubuntu or Debian seems to be Nodesource, whose installation instructions say to run:

curl -sL https://deb.nodesource.com/setup_12.x | sudo -E bash -

This clashes with some basic security rules I learned long ago, such as "be suspicious of downloads" and "be cautious with sudo". However, I learned those rules long ago, and nowadays it seems like everyone is doing this...well, at least it has 350 upvotes on askubuntu.com.

As I read various opinions on other sites, I'm finding that some people also think curl-pipe-sudo-bash is unsafe:

• Phil. (idontplaydarts.com, 2016-04-19) Detecting the use of "curl | bash" server side


• Stemm, Mark. (Sysdig.com, 2016-06-13) Friends don't let friends Curl | Bash.


• 
  Stackoverflow.com. (2015-04-01 and onward) Why using curl | sudo sh is not advised? (also linked from askubuntu)

while some people think it's just as safe as any other practical installation method:

• McLellan, Bryan. (Github.com/btm, 2013-09-25) Why curl | sudo bash is good.


• YCombinator.com. (2016-10-22 and onward) "Curl Bash piping" wall of shame.


• 
  Varda, Kenton. (Sandstorm.io, 2015-09-24) Is curl|bash insecure?.

There are also some that explore the problem without giving a decisive opinion:

• Granquist, Lamont. (Chef.io, 2015-07-16) 5 Ways to Deal With the install.sh Curl Pipe Bash problem.

Since there's no clear consensus from other sites, I'm asking here: Is curl-pipe-sudo-bash a reasonably safe installation method, or does it carry unnecessary risks that can be avoided by some other method?

It it's about as safe as any other installation method as long as you:

• Use HTTPS (and reject certificate errors)


• Are confident in your certificate trust store


• Trust the server you're downloading from

You can, and should, separate the steps out -- download the script, inspect it, and see if it's doing anything fishy. This is a good idea. It won't hurt anything if you do it and you might catch a compromise, which you can report to the source and the community at large. Be prepared to dig through quite a lot of Bash, if my experience with such things is any indicator.

Be aware that if the server (deb.nodesource.com) is compromised, you basically have no recourse. Many package managers offer to verify GPG signatures on packages, and even though a fundamental part of the keysigning architecture is broken, this does still by and large work. You can manually specify the CA for wget and curl, though this only proves you're really connecting to that server, not that the server is serving safe code or that it's legitimate code from the creators.¹

If you're worried about arbitrary code execution, APT definitely allows that, and I'm fairly confident both Homebrew and Yum do as well. So comparatively, it's not unsafe. This method allows greater visibility; you know precisely what's happening: A file is being downloaded, and then interpreted by Bash as a script. Odds are good you have enough knowledge already to start investigating the script. At worst, the Bash may call another language you don't know, or download and run a compiled executable, but even those actions can be noticed beforehand and, if you're so inclined, investigated.

As a side note, given that a lot of the time you need to install things with sudo, I don't see its use here as any special concern. It's mildly disconcerting, yes, but no moreso than sudo apt install ....

^{1: Then again, it looks like NodeSource is creating some sort of custom installer, which wouldn't be signed by the Node team anyway, so... I'm not convinced that it's less safe in this particular case.}

Submitting an answer to my own question. Not sure if this is the best answer, but I'm hoping other answers will address these points.

curl something | sudo bash - on Linux is equally safe as downloading something on Windows and right-clicking run as administrator. This may or may not be 'reasonably safe'. As a recent xkcd suggests, nobody really knows how bad computer security is these days.

Several risks of this method can easily be solved by verifying the download integrity before running it. Since doing so is simple, there's no good reason to skip this step. The goal here is to ensure that what you have downloaded is what the publisher intended. This doesn't guarantee that the software is free of its own vulnerabilities, but it should at least protect against simple attacks that replace the download with malware. The essence is simply to verify the MD5 and SHA256 checksums posted by the software publisher. Some further improvements are possible:

• It's better to get these checksums via a different network path, such as by calling a friend in another country, which would protect against MITM attacks.


• It's better to get the checksums at least a day earlier/later, which would protect in case the publisher's website was briefly taken over but the takeover was stopped within a day.


• It's better to verify the checksums themselves using GPG, which would protect in case the publisher's website was compromised but their GPG private key wasn't.

One side comment: Some sites say you should download the sh script and then inspect it before running it. Unfortunately, this gives a false sense of security unless you vet the script with a practically impossible level of precision. The shell script is probably a few hundred lines, and very tiny changes (such as an obfuscated one-character change to a URL) can convert a shell script into a malware installer.