[e12e]

Depends. On windows an installer might be signed. On Linux a package should be signed.

You can't know that curl and your browser get the same data - but you can for example split it up:

  curl https://pyenv.run -o install.sh
  #examine install.sh
  bash install.sh

Ed: or just "save as" like with an installer.

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.

[maccard]

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.

[e12e]

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

https://github.com/helm/helm/blob/v3.6.2/scripts/get-helm-3#...

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.

And just for completeness - a reminder that any cut'n'paste in the terminal is a bad idea: https://nakedsecurity.sophos.com/2016/05/26/why-you-cant-tru...

[maccard]

Completely agree with everyhing you say here!

[e12e]

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

[maccard]

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.

[e12e]

It's a little easier to read a 10 line bash script than a 35 mb binary installer?

[maccard]

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.

[e12e]

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