You are piping the output of an untrusted command into a shell that will execute it. This leaves no way to verify that the code your are running is legit. No md5 verification, no cursory inspection of the script, etc.... There could even be hijacked dns that points to a server that specifically does a bad thing. Maybe not a huge deal for small projects but it's not a great idea in general.
HTTPS is an entirely different story, I don't know that people would necessarily like installs like "curl https://my.script.ly | sh", but there's at least a mechanism to verify the identity of the source.
You are asking developers to download a shell script from $random_site and run it immediately without any thoughts whatsoever as to what effects it might have.
The biggest problem is validating the download prior to installing it. The use make install or install.sh or other similar script, the following should be done:
Download package
md5 package
verify md5 == published md5 of packge
extract
make install / install.sh / etc
With "curl package.github.com" | bash" the validation is missing. I don't mind the curl x | bash for my dev machine or testing/dev vms, but that is not happening on production. And if I need said software on production, I have to find a different way to install.
If the bad guy has intercepted the DNS, they can just provide the md5 of the bad script, no?
That's enough extra work, and unreliable enough, that the attacker might not bother. Why work so hard to sabotage the user who checks md5sums when you can just wait for a user that doesn't? Just because thieves can carry lockpicks doesn't mean that you shouldn't bother locking your car: Protection against lazy, opportunistic thieves is still better than nothing.
The other advantage of the MD5 plan is that you can download the MD5 from a different site than the script, at a different time and over a different internet connection (or, perhaps, over https). A specific, important version of that use case is: If you're installing the script over and over again in an automated fashion, you can download its MD5 in advance, cache it, and then check it against every future download of the script to verify that the script hasn't changed. When the script gets updated and the MD5 legitimately changes, you audit the diff and then update your copy of the MD5 for the future.
Meanwhile, using curl-over-HTTPS seems like it couldn't hurt, but better make sure 'curl' is really checking the cert and aborting on cert mismatch, because tools can be very sloppy about this. Also, you're still trusting the third party site, and once their site gets hacked it's game over… unless you have another canonical source for the MD5 sum.
One ultimately realizes why real packaging systems have signed packages, with private keys assigned to developers.
