== The problems with piping curl to a shell are system management ones I was recently reading Martin Tournoij's [[Curl to shell isn't so bad https://arp242.net/curl-to-sh.html]] ([[via https://lobste.rs/s/lz7tit/curl_shell_isn_t_so_bad]]), which argues that the commonly suggested approach of using '_curl example.com/install.sh | sh_' is not the security hazard that it's often made out to be. Although it may surprise people to hear this, I actually agree with the article's core argument. If you're going to download and use source code (with its autoconfigure script and '_make install_' and so on) or even pre-build binaries, you're already extending quite a lot of trust to the software's authors. However, I still don't think you should install things with curl to shell. There are two reasons not to, one a general system management one and one a pragmatic one about what people do in these scripts. The general system management one is that to manage and maintain your system over time, you need to control what changes are made to it and insure that everything is handled consistently. You don't want someone's install script making arbitrary and unknown changes to your system, and it gets worse when that install script can change over time. The ideal thing to install is an artifact that you can save locally and that makes limited and inspectable changes to your system (if any). Good install options are, for example, a self-contained tarball that you can extract into a directory hierarchy of your choice (and that doesn't even have to be owned by or extracted by _root_), or a package for the standard package manager on your system that doesn't contain [[peculiar custom scripts with undesired side effects https://twitter.com/thatcks/status/1192901374985613312]]. An un-versioned shell script fetched from a remote end that you don't save or inspect and that will make who knows what changes on your system is a terrible idea for being able to manage, maintain, and understand the resulting system state. The pragmatic reason is that for some reason, the people writing these install shell scripts feel free to have them make all sorts of nominally convenient changes to your system on behalf of their software. These shell scripts could be carefully contained, minimal, and unchanging (for a particular release), doing very little more than what would happen if you installed a good package through your package manager, but very often they aren't and you'll wind up with all sorts of random changes all over your system. This is bad for the obvious reason, and it's also bad because there's no guarantee that your system is set up in the way that the install script expects it to be. Of course generally '_make install_' has the same problem, which is why experienced sysadmins also mostly avoid running that as root. (More generally, you really want to manage the system through only one thing, often the system's package manager. This is [[the problem with CPAN and other independent package systems CPANProblem]] (althogh [[there are good reasons why people keep creating them ../tech/WhyNewPackageManagers]]). Piping curl to a shell and '_make install_' are just magnified versions of it. See also [[why package systems are important PackageSystemImportance]].)