curl -s -L https://raw.githubusercontent.com/Groxx/rickrollrc/master/roll.sh | bashAnd if you're facing an attacker sophisticated enough to send different contents to a browser and to curl, then you're probably not going to find their backdoor in the first place. And it would be stupid of them to depend on that trick, so this becomes an extremely niche case not worth worrying about.
And multiply that sophistication by a hundred times because this is on github servers.
The "what if the file is truncated" issue is the only realistic one, and competent installers like this one define functions and don't run them until the last line.
But it makes it way easier to figure out what happened if you do get attacked.
With "curl | sh" if a compromised site only sends the attack code randomly and I get unlucky I won't have a copy of the attack code afterwards. If I go to the site to grab a copy I'll probably get a copy without the attack code.
With "curl > /tmp/foo.$$; sh < /tmp/foo.$$" if I am unlucky and get the attack code I can at least look at /tmp/foo.$$ to see what happened, and download the code again and see if it is the same.
If you insist on piping, at least do "curl | tee /tmp/foo.$$ | sh".
Checking the Accept header (or User-Agent or a bunch of other things) is very difficult :)
> terminals don't have even a small fraction of browsers' malicious-link-defense mechanisms (as demonstrated). I always want to see the full url in a terminal.
And yeah you're right if you're just piping stuff to bash, malicious URLs are the least of your worries, but that doesn't change the fact that outputting data (that may contain raw control codes) to your terminal is dangerous with or without linkified-URLs.