If you think about the open-source security model, it's arguably more based on auditing than anything else. Because everyone can see the same code, we like to think someone will notice a problem. curl|sh breaks that because people might get different code.
A reasonable alternative is to replace the paste-able curl|sh command with a paste-able command sequence which 1) downloads the install script and saves it to a file 2) verifies a checksum on that file 3) executes it
2/2
@mppf *Any* download mechanism can serve different files to different people. Your idea just moves the attack point to the web server serving the instructions, such that they serve different checksums to different people, to match with the different files they're going to get.
You are just one more person arguing against curl|sh while completely missing that the problems you raise literally apply to every other competing approach. Seriously, stop and think please. I'm tired of having the same conversation over and over again.
The only way you can verify *anything* is against an existing root of trust, and the only root of trust that exists on the system is the WebPKI, which means you can trust a server is not spoofed, and yes, means you still have to trust the server itself, because there's no way around that (other than switching to Apple's walled garden codesigning, which has its own root of trust and yes, is in the cards some day, but that's a much more difficult project and it's never what the anti curl|sh people actually suggest).
@mppf *Any* download mechanism can serve different files to different people. Your idea just moves the attack point to the web server serving the instructions, such that they serve different checksums to different people, to match with the different files they're going to get.
You are just one more person arguing against curl|sh while completely missing that the problems you raise literally apply to every other competing approach. Seriously, stop and think please. I'm tired of having the same conversation...