Just like a castle with a water pit can still be conquered, but it takes a bit more effort for achieving it.
What's wrong with this? It's no worse than git clone && make
or any of the other hundred incantations of executing code from the web.
It's true that the vast majority of the time a "curl | sh" works fine and does just what you expect it to do, but that's not really the point. The point is that you have no idea what that script your piping will do. You also have no idea whether in this case the binary it fetches is actually built from the code the service says it is; downloading the script first and inspecting it is a good idea, but still not as good as building directly from the code.
This is why we see people do things like publish a hash sum alongside binaries they offer, or use a digital signature. Then we can at least verify that a binary matches what the author says they released, or better yet ensure that the binary was produced by a trusted source.
You can just not pipe the curl script to shell and inspect it [0]. Executing that is no worse than executing a random make command or `brew install`
> downloading the script first and inspecting it is a good idea, but still not as good as building directly from the code
No, you need to inspect the code too if you're that worried. I can write a makefile that just does this: build: curl http://example.com -o bad.txt && cat bad.txt
Either you're actually vetting what you run on your machine, or you're not. curl | sh isn't any worse than git clone && make.
> This is why we see people do things like publish a hash sum alongside binaries they offer, or use a digital signature. Then we can at least verify that a binary matches what the author says they released, or better yet ensure that the binary was produced by a trusted source.
So just publish the hash/signature next to "install instructions" that contains the curl command, and let the user verify the hash themselves. Again, that has nothing to do with the install method.
