Is this much worse than downloading some installer and running it? Those can be just as compromised. So can packages in package managers for that matter.
Piping straight to bash can be especially bad if you've cached sudo credentials for the current session - some of these scripts call sudo "inside".
Otoh - the connection is signed (it's https)-unfortunately it's often quite easy to compromise a web site. Obviously, listing gpg signatures on the same page doesn't add much unless it's possible to verify the gpg key some other way.
Ed: another problem is that you really should check exactly what's in you clipboard before pasting to a terminal.
The safety in your steps is reading the script, not in avoiding curl | bash. An installer being signed doesn't guarantee it's not malcious; if someone has overtaken a host and replaced the binaries, they'll just sign them themselves. Unless you're manually inspecting the signature matches your expected source, running a signed binary doesn't save you.
True, it does not. I don't recommend downloading (random) binary installers and running them either.
With eg Linux isos, you typically already trust the signing key for your os updates.
But unless you are vigilant about your ssl root certs, you'll easily allow a lot of malicious and incompetent services to potentially intercept most of your ssl traffic... (due to there being many trusted roots by default).
> if someone has overtaken a host and replaced the binaries
This again depend on who and how the binaries are signed, and how the signatures are trusted. Typical windows (and Mac?) setups will gobble up any signature. But if you do check who signs the binaries - then the signing key will easily be the most secure part of the system - a compromised ftp/web site allow hosting malicious binaries, but typically not grant access to the signing key.
With letsencrypt a hacked web site will typically have access to a valid ssl cert - no need to further compromise mx/mail records or gain access to a business phone number etc.
A ascii-armor signed shell script can be distributed safely via a paste-bin. Unfortunately there's no good automatic/standard way to do so. Or rather no standard tool to prompt to trust the signing key - and then run the script - beyond basic gpg --search-key --key-server.. + gpgv.
Maybe signed git repos would be easiest - but I don't know how easy it is to limit which keys are trusted - if it's possible at all?
The helm project does a little dance to try and verify downloads - but for all the effort it pretty much amounts to trusting the script, not the keys/signatures:
I was hopeful sequoia might help - but apparently its sqv tool is even worse than gpgv - neither can handle an ascii armored public key, and sqv can only handle detached signatures.
> The safety in your steps is reading the script, not in avoiding curl | bash
Well, yes. The safety is in doing something between "acquire potentially malicious payload" and "running payload". I don't see how "safety [is] not in avoiding curl | bash" when, avoiding the direct pipe to bash is exactly what I suggest.
If you look at the url, then curl and pipe that url, you have no idea if bash sees what you just reviewed.
But you have exactly the same problem with downloading a binary, or running pip install. You have no idea what that code does, so curl | bash doesnt hurt any more than any other normal methods of installation.
Do you read the source of every setup.py you run before running pip install? Also, if you are untrusting of the source enough to verify their install script is safe, why would you install their template to run on your machine without verifying all of that too? Finally, 10 line bash script might (as tbis example does) just call out to another curl | bash, or to a pip install/npm install.
> Do you read the source of every setup.py you run before running pip install?
I generally run make, setup.py, cargo build etc in the context of cloning a source repository. I certainly could do a better job of sanity-checking those things, but I do try. And I definitely try to avoid having sudo credentials cached when I do - to foil "sudo cp artifact /usr/sbin" and other awful things people do, because they found it convenient.
> Also, if you are untrusting of the source enough to verify their install script is safe, why would you install their template to run on your machine without verifying all of that too?
I generally trust people more to write "left pad" than install scripts. Many sysadmins are good programmers, few programmers are even remotely decent sysadmins in my experience.
> Finally, 10 line bash script might (as tbis example does) just call out to another curl | bash
In which case one has to chase down the rabbit, or give up.
Sometimes one will discover that the end game was downloading a gpg signed tar archive with the release artifacts - and one can go and do that.
> or to a pip install/npm install.
People do do awful stuff in makefiles and package install scripts, but for vanilla python/Javascript - the lazyness of programmers tend to work to our advantage - there be little extra madness/magic in there.
Sute, running pip install -r requirements.txt can do almost anything - but it's unlikely to run your package manager under sudo and mess up your system packages, or add something questionable to your package sources.
> Is this much worse than downloading some installer and running it?
Yes.
You should inspect what you download.
Also, you should probably use the Python interpreters provided by your Linux distro, that stay in directories you usually can't write to and come in signed packages. On a Mac, the next best thing would be MacPorts.
Nothing here overrides there system wide Python version.
The article specificially goes into why not to do it.
> pyenv allows us to set up any version of Python as a global Python interpreter but we are not going to do that. There can be some scripts or other programs that rely on the default interpreter, so we don’t want to mess that up.
Using the Python interpreters in your system doesn't mean you can't make virtualenvs out of them - it's just that they are precompiled and well supported on your specific OS.
I used custom Python interpreters a lot and it's nice to be able to rely on the system to provide a sensible environment instead of forcing myself to build my own.
That's why the traditional Windows way of downloading a setup.exe and running it with admin privileges is a bit scary for people coming from other platforms. Installing an .msi is less bad, or so we are taught.
