[tomsmeding]

It's still executing code right from the internet without any checking. What it does fix is one of the ways in which a server can tell that a script is being executed and not just downloaded for reading: when piping, the download stalls while the shell is slugging through the script, but when it's done in a shell escape as here, it's downloaded in one go. So theoretically, you have less chance of reading something different (when inspecting the source) than what the shell is going to execute.

However, the script can't be overly long this way, since there is a limit to the command line length on Linux.

Safe, however, this is clearly still not.

[aaronkjones]

By safe do you mean there is something insecure with redirecting output in this manner or do you mean one shouldn’t sh -c $(wget... without first checking the source of what they’re downloading?

[aaronkjones]

*By unsafe

[tomsmeding]

Mostly the second, you should check what you're downloading and executing. But a server can send two different files on two similar requests, ans perhaps it sends you a "good" file when you view it in your browser and a malicious file when downloading it via wget.

When piping, there is a well-known trick how the server can detect the difference even disregarding stings like the user agent header, but that trick doesn't work when you do $(wget ...). But I won't guarantee there isn't some other trick that can be performed.