[doix]

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.

[0]: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

[maccard]

> its also possible to detect when someone is piping to bash (on the server) and serve a different payload.

If you have a fear of your source maliciously serving you different code over curl, don't run their code at all.

> You're better off piping curl to a file, reviewing the file and then running it manually.

Right, but the safety there is reviewing the code. Running brew install, npm install, pip install, or a binary could all run malicious code too.

[KronisLV]

Shouldn't there be some CLI tool that would allow verifying the checksum of the file as an intermediate step?

Something along the lines of:

  curl https://pyenv.run | pass_on_through_sdtout_if_hash_matches md5 8bffaf30c9ba21393329d531063056fe | bash

That way, someone who validates the file locally, can be sure that what's piped is the same thing.

[maccard]

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.

[KronisLV]

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.

[maccard]

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.

[nerdponx]

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.