[maccard]

What's the problem here?

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.

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

[jayknight]

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.

See http://thejh.net/misc/website-terminal-copy-paste

[Cthulhu_]

The request itself won't be tampered with, but what if the host was? That endpoint could be compromised and send you a different script.

They should offer a download with signature validation instead. Signed by Apple, Microsoft, etc if possible.

[maccard]

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.

[0] https://arstechnica.com/gadgets/2021/06/microsoft-digitally-...

[dragonwriter]

> The request itself won't be tampered with, but what if the host was?

What if your distro package repository was?