If you're claiming that you don't get the ability to audit the code, I'd like to watch you audit a ./configure shell script generated by GNU autoconf.
If you're claiming that you want to apt-get install so the package maintainer has audited the code, I'd like to watch them audit the ./configure shell script.
Downloading and auditing code from an untrusted source is security theatre. Don't install it at all, if you don't trust it. Or use some platform (the web, iOS, Android, Qubes, etc.) that makes it such that there's no need to audit it because the app is restricted in what it can do.
Yes. Wrap the entire script in a function and call the function at the end once the whole thing has transferred. https://install.sandstorm.io/ , for instance, does this.
At least wrap the dang thing in a function and execute the function. That way you don't get partial execution if the HTTP connection manages to die halfway through.
Unless I misunderstood their description, they can man-in-the-middle for the disposable keys use-case anyway. If you don't trust them, don't use the software. I don't really mind having curl|sh installation instructions as long as they use https and the script is written so that truncated downloads don't cause any harm. If you know that this is a risky way of installing software, nothing prevents you from manually verifying the installation script or following the manual installation instructions. Everyone else probably doesn't have the means to properly evaluate the downloaded software anyways.
Can you explain to me the fundamental difference between this and sudo apt-get install?
Note that the curl command is on an https resource. Yes if the https server is compromised there's a problem, but that's true with any other delivery method.
I'm being facetious as the answer is there isn't one
>Yes if the https server is compromised there's a problem, but that's true with any other delivery method.
That's not correct. In most distros, installing packages from your distro's repositories has an additional security guarantee: the packages you download have their PGP signatures verified before installation. If an attacker compromises the web server and alters the package, your package manager will reject it as it's not signed by a trusted key in your keyring.
That is true for distribution-hosted repositories. But how many web sites are there that are like, "Add this line to sources.list, then run this apt-key command, and then run apt-get install our-app." So few people bother to check for a web of trust for the proffered key (or even know how to, or even grok the concept) that there is little functional difference.
If you're claiming that you don't get the ability to audit the code, I'd like to watch you audit a ./configure shell script generated by GNU autoconf.
If you're claiming that you want to apt-get install so the package maintainer has audited the code, I'd like to watch them audit the ./configure shell script.
Downloading and auditing code from an untrusted source is security theatre. Don't install it at all, if you don't trust it. Or use some platform (the web, iOS, Android, Qubes, etc.) that makes it such that there's no need to audit it because the app is restricted in what it can do.