[db48x]

There are three main problems with curl | sh: the file one the web server could be replaced without modifying the source in version control (and unlike a git checkout, the hash of the file is not verified), you can’t read the code before it runs, and curl could fail to download the whole file.

Of course, I bet a lot of people don’t bother to read any of the source code of a program that they’ve downloaded anyway.

[slimsag]

Downloading a tarball and running ./configure from it (pretty dang common) also does not have the changes checked into version control, nor the hash verified.

Same is true of `npm install`, deb/rpm/etc packages, etc: you don't have proof what was distributed to you matches up with what was in VCS.

You can read the code before it runs and solve the "curl could fail" theoretical arguments by just.. removing `| sh` and examining + running yourself.

[db48x]

I agree; distribution via git is better in many ways than distribution via tarball. I believe that npm and similar package managers mostly pull code from git repositories. Of course, even then you might want to double check that the package name hasn’t been hijacked or sold off.

Of course you can break the curl|sh into separate steps and check that the script isn’t malicious before you run it, but the fact that you have to do that makes it a bad idea to distribute software this way. If you were told to download an installation script, inspect it, and only then to run it then there would be less of a problem. curl|sh is yet another sign that we so often prefer convenience over reliability and safety.

[deadbunny]

Debian are working on reproduceable builds for apt. Not there yet but going in the right direction.

https://wiki.debian.org/ReproducibleBuilds

[fiddlerwoaroof]

You can solve the third problem by declaring a shell function `install` that is run at the send of the script. The first problem is a problem but, as far as I know, most language package managers don’t verify provenance anyway: yarn install foo can perform arbitrary side-effects either directly or through its transitive dependencies.

[mprovost]

You can break the pipe and curl the file first, read it, and then run it. But I doubt that anyone ever reads through the thousands of lines of m4 that come with a typical program that uses autoconf either.

[db48x]

If the project uses Autoconf/Automake, then you can just read the .in files instead. If they include anything unexpected, then it will be pretty obvious (since anything unexpected will be a lot more complicated–looking than anything normal). But if they do include a bunch of custom m4 files, then you’re going to be spending more time on it than you would want.