3 ms·
The website could be compromised though, and you'd have no reliable checksum to compare against (unlike a proper repository). Similarly to what happened to e.g
by laurentdc 10y ago
The website could be compromised though, and you'd have no reliable checksum to compare against (unlike a proper repository).
Similarly to what happened to e.g. https://transmissionbt.com/keydnap_qa/ https://transmissionbt.com/keydnap_qa/ or http://www.classicshell.net/forum/viewtopic.php?t=6441 http://www.classicshell.net/forum/viewtopic.php?t=6441
- eridius 10y agoThis is not a risk inherent to `curl | sh`, it's a risk that you run any time you download software from anywhere that doesn't have a signature using a key that you've already previously verified as trustworthy.
- falcolas 10y agoWhich is why most package managers for installling software use signatures. .msi, .deb, .app, .rpm... all provide methods for signing code, and can refuse to install code without signatures or improper signatures.
- eridius 10y ago`curl | sh` isn't used as an alternative to package managers, it's used as an alternative to "download this script and run it".
- jjnoakes 10y agoNot sure why you are being downvoted, you are completely correct.
- falcolas 10y ago`curl | sh` is not an alternative; it is exactly download this script and run it. The problem is "to what end". Most of the time, the script being run is installing software. Be it Docker, Prometheus, homebrew, or otherwise, the entire purpose of most of these scripts is to install software. So, why not just install using a package manager that takes some actual security precautions? The answer is, most of the time, that software developers are either "moving too fast" (docker is guilty of this, but at least they are using the underlying package manager) or more often are just too lazy to provide packages through authenticated channels.