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.
> 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.
I think it'll compile various Pythons on your machine under your user. I'd prefer to install (learned this today) with Homebrew multiple versions (not sure how possible it is) as `brew install python@3.6 python@3.7 python@3.9` (because Big Sur has 3.8 built-in).
In reality, I'm a more traditional Unix person and prefer MacPorts, where you can do `sudo port install python36 python37 python39` in a very BSD way of doing things.
Homebrew has broken my computer one time too many.
The script is served over https, so it's not going to be tanpwred with (unless you have a malicious cert, but at that point you can't trust anyone), and curl | bash isn't any worse than downloading a script and just running it, or running a precompiled binary you don't trust.
pyenv could get taken over and you won't know. It's also possible to detect when someone is piping to bash (on the server) and serve a different payload [0]. You're better off piping curl to a file, reviewing the file and then running it manually.
Yes, there absolutely should be. It would be a massive improvement if that happened.
It requires a few extra steps to be actually secure. You actually need to verify the hash from a trusted source for it to be actually secure. If the delivery has been tampered with, you need to ensure that the delivery of the hash has also not been tampered with. In practice, codesigning is the solution, but certs are expensive, and impractical for a small project.
How about the hash being something that you calculate locally?
1. (local) Download the file from the URL.
2. (local) Review it locally, in a text editor.
3. (local) Get its hash locally, from the file in your file system.
4. (SSH) Feed this hash into the fictional tool above.
5. (SSH) If what curl gets is the same as the file that you've reviewed, it gets piped further into bash, otherwise the execution stops and an error is output.
Of course, that's only applicable to this particular case, where a compromised server could detect that a bash pipe is used and return different file contents. That would only be useful in situations where you want to review it on a local device, such as a desktop and run it on a remote one, such as a server.
Edit: If you want to review it remotely, there's nothing to prevent you from using less or something to view it before manually opening it with Bash. That just requires the discipline to not use one liners that both download and run it, as long as no such tool like the above exisdts.
I cant believe I'm going to suggest a blockchain but I think what you really want is:
- run `cu-sh example.com/questionable.`
- this uses `$editor` to let you review the contents (skippable with a command line flag)
- generate a hash of your local contents
- check said hash against a blockchain to see if everyone else who got it got the same contents as you.
- decide from 1 and 2 above whether you actually want to proceed with the install.
You could replace blockchain with checking if it's signed, and the key matches an owner on keybase/github/some other federated identity provider too.
You often want to do this anyway, because the installer often supports various options and env vars. If you download the file you can read its --help output, and even keep it on hand in case something bad happens, or just for your own records.
It's also possible for you to copy things you can't see from web pages. So the command(s) you end up with may not be what you thought. So there's a trust issue with the site you get instructions from ass well.
If you're afraid the host may be untrusted then you would be wrong to download any of their code at all.
The safety is in reviewing the code there, not in avoiding curl | bash. Running pip install or npm install is just as dangerous.
> They should offer a download with signature validation instead. Signed by Apple, Microsoft, etc if possible.
If the host is compromised, the attacker will just get Microsoft to sign their malware instead; see [0]. If the host is compromised, and you run the code without reviwing it, you're hosed regardless.