When you run third-party code on your system there is ALWAYS a risk of it doing nasty things, it doesn't matter if it's an easily readable bash script or a .deb you downloaded. The biggest argument I see about curl | sh that I can agree with is the issues that happens when your connection dies in the middle of the download. Just download the file, then run it.
I don't think anyone is against recommendations of running "curl trustedsite.com/install | sh" except for the bad habits it teaches to people who don't know what curl and sh actually do, but wouldn't download and run a random exe.
Help forums are rife with suggestions to run "curl http://pastebin.com/raw.php?i=XXXX | sh" to solve technical problems. And not fringe forums either, but forums like the official Ubuntu forums.
I've literally never heard anyone "preach that curl | sh is evil" who wouldn't/isn't saying the exact same thing about binaries.
I didn't submit it here because it wasn't really meant for an advanced crowd, obviously most people would be aware of the dangers.
For example, take a look around at the pirating world. Many sites that help you install projects such as Couchpotato, Sickbeard, Sabnzbd etc rely on people curl-piping bash scripts. The people installing from those scripts likely do not know any better.
Now while even with binaries people might now actually do that often enough - it at least is still an option.
Truth is I'd rather read someone else's shell script than someone else's C, python, ruby, javascript or other code. Not to say it still isn't painful reading; most scripts I see are nonsensically verbose. But it is a much less time-consuming read.
Unless, of course, it is written in a shell like Bash, i.e., one with too many extra features to keep track of. Like, say, exporting of functions, for example.
We preach that curl | sh is evil because of a potential lack of
transparency but rarely does anyone denounce the evils of binary
packages.
This is "Freedom 1"[1] and a bedrock principle of the FSF.[2] Applebaum recently gave a talk "Free Software for Freedom Surveilance and You" about the evils of binary packages.[3][1] https://www.gnu.org/philosophy/free-sw.html
[2] Free Software is Even More Important Now: https://www.gnu.org/philosophy/free-software-even-more-impor...
[3] https://media.libreplanet.org/u/zakkai/m/free-software-for-f...
rm -rf /tmp/myawesomeinstaller
Is this likely to cause a catastrophic failure? No. Is it possible? Absolutely.
But still, curl > script,read, run and youre good to go.
Just dump the data into a file:
curl > foobar
Read the file using any number of normal utilities
vim foobar
cat foobar
nano foobar
less foobar
Then if you like what you see execute the file
sh foobar
Linux/Unix utilities are meant to be used. Don't limit yourself to only knowing how to check the contents of a curl install if you have a curlsh function.
If they can't read it, they likely wouldn't even know how to install it.
Disclaimer: I wrote this article in Aug of last year.
the "No, I don't want to run this" way to exit is to wipe the file and save it empty.
the "I do want to run this" way is to just exit normally
opening something and going "wow this is actually damaging, I'll just exit, ^X... waitfuck" seems something that is more than possible
or in short, the default state is to execute the file
1) Find a source you trust (nominally)
2) Get a gpg-key that you trust belong to that user
3) Get the install.sh script
4) Get the matching gpg signature (install.sh.asc)
5) Verify that 4) is a valid signature of 3) under 2)
6) Have a look at the script
7) Run the script
If you can't establish 2), you'll just have to stick to 3) 6) and 7).Seeing that something is on a https site, just means someone had the access to put it there. If someone got access to the private key behind 2) -- 1) is probably so compromised that there isn't anything other than 6) that might protect you -- and if the script is truly malicious (as opposed to just your average botched bash script) -- it's not guaranteed that it's obviously malicious.
Anyway, a gpg signature links some distributable the author has verified all the way back to wherever that file was authored -- while https only anchors trust on the web server. Web servers get compromised all the time. Prefer a proper signature as a means to anchor trust ("yes, this is probably what X wanted to distribute. If you trust X, this is probably OK").
A https signature just means: "This is something someone/anyone managed to upload to this web server".
http://drj11.wordpress.com/2014/03/19/piping-into-shell-may-...
{ echo { && curl https://thing && echo } ; } | sh... by running this script i'm hosting on the internet.