Discussions: Hacker News.

Piping curl to s(hell) claims that using curl example.com/install.sh | sh to install software is a “glaring security vulnerability”. I’ve seen this claim many times in other places as well, with strong terms like “malpractice”.

I don’t get it. you’re not running some random shell script from a random author, you’re running it from a software vendor who you already trust to run software. Are you going to audit all of oh-my-zsh? Probably not. So why give extra gravity to their install script? If you trust oh-my-zsh, then why distrust their install script?

There is no fundamental difference between curl .. | sh versus cloning a repo and building it from source. Do you know what’s in ./configure? GNU configure scripts are tens of thousands of lines of unreadable autogenerated code. No one audits that and it’s the perfect place to hide nefarious commands.[1]

It’s worth pointing out that the install scripts for all the cited examples are in source control[2], and subjected to the same kind of auditing as the software itself. Of course, there is no hard guarantee that the file in git is the same as the one you download from https://sh.rustup.rs, but you also have no guarantees that https://rust-lang.org/rust-1.39.tar.gz is really the same as git, and I don’t see anyone calling this a “glaring security vulnerability” or “malpractice”.

The only real difference I see is that curl | sh is a very direct way to run code from the internet, whereas the other methods are running code from the internet, but with extra steps. It may “feel” different, but in reality it’s just the same. In the end it’s still just running code you didn’t personally audit on your computer, and a matter of trust.

To break down the bullet points in the article in some more detail:

  1. You can regenerate them from autoconf, but I don’t think many do? Even systems like FreeBSD ports just use existing configure scripts. 

  2. oh-my-zsh, calibre, docker, yarn, rust