Another reason why piping the outputs of curl into bash is a security risk

Really early on in my computing career I remember people making fun of people who piped the output of things like curl directly into bash. It was the sort of thing that people knew was insecure and could cause all sort of problems. As a result people would explain to other people why it was a really dangerous/bad idea to copy and paste shell commands like sudo curl example.com/somefile.sh | bash and run them.

Lately I've been encountering a lot of projects where the explicit suggestion for installation in the readmes is often something along these lines. And this isn't something limited to small projects either, I've seen this in bigger projects too.

Now there's all sorts of reasons why I think this is bad, firstly you need to trust that the file you are receiving is not malicious. This first means you need to know that the URL you think you are fetching the file from is the URL that you are actually getting the file from. There's a number of MITM style attacks that could make this an issue. I've had people in the past tell me that you should just download the file first and verify it works before you run it again on other machines, but that's actually insufficient for a few reasons including...

A whole new aspect of why this approach is bad I came across today, which is that it might be possible to detect curl piping into bash on the server side. What this means is that a malicious actor could set something up such that if they detect that you used curl to pipe into a file they can send a different file to you such that attempts to verify that the file was not malicious before running it could be somewhat circumvented. If you then ran what looked to be the same command but piped into bash (for example you are making a script or running the command on a different machine) then with those invocations you could get some other version of the file from the server.