5 ms·
> Unfortunately I was stupid enough to ddg it (duckduckgo it, as opposed to google it) and apparently this exact use-case was previously the recommended way of
by jkyle 11y ago
> Unfortunately I was stupid enough to ddg it (duckduckgo it, as opposed to google it) and apparently this exact use-case was previously the recommended way of installing RVM[2]
Not only "previously", it's the current recommended way to install rvm. From their front page:
>> curl -sSL https://get.rvm.io https://get.rvm.io | bash -s stable
[1] http://rvm.io/ http://rvm.io/
- stephenr 11y agoOh I agree there are problems still, but its an improvement over the previous - it's using HTTPS and it's calling the RVM domain - before it was plain HTTP to bit.ly
- sciurus 11y agoAlso the installer is now signed via GPG. https://rvm.io/rvm/security https://rvm.io/rvm/security
- acveilleux 11y agoBut then there's a circular dependency because the GPG key is retrieved by the bash script that is wget'd.
- lmm 11y agoIt doesn't have to be circular. The script is secured by HTTPS (and hopefully has the key embedded in the script itself?) which can then retrieve the installer and verify it using the key.
- acveilleux 11y agoThe problem is that in this scenario, the GPG key and signature serves no practical purpose. The whole security, whether GPG is invoked or not, relies on the security of the HTTPS connection alone. If the HTTPS cannot be trusted alone, then everything is lost as a compromised HTTPS connection can be used supply both a comprimised GPG key and a compromised package, or, indeed, anything at all that is legal to `| sudo bash`... And HTTPS security boils down to: 1. The difficulty of altering (or exploiting privileged position wrt) the global routing table to setup MitM or MitS scenarios. 2. The difficulty of obtaining a valid looking certificate for an arbitrary domain. Any situation where a government actor is the adversary poses intractable challenges to both 1 and 2 above. (And before you say NSA/GCHQ would never care about XYZ, consider China...
- emn13 11y agoEven if you trust "normal" https certificates, it's still a much more risky proposition. Those certificates only really say that somebody control the domain - not (in general) that he actually owns it or is responsible in any way, and, more critically, don't vet whether somebody is trustworthy or not. You can easily get some other similar-sounding domain as a malicious agent, and validly get an https certificate for that. So even if you trust https works, it's still a tricky proposition - it's not really similar to a distro's package distribution channel.
- acveilleux 11y agoIndeed, and I didn't even go over trusting the actual source of the bash script or the security/integrity of the server(s) it's hosted on even if the cert is all A-OK.
- lmm 11y agoIt gives people a way to choose the level of security they care about. Those who are willing to trust HTTPS can trust HTTPS. Those who aren't can obtain the GPG key and check its signature by another mechanism (WoT) and manually verify the package signature.
- acveilleux 11y agoThose who would go out of their way to do the GPG check are also the same people who are horrified by `curl .... | sudo bash`
- lmm 11y agoYes, that's the point. Those who aren't horrified can do that. Those who are can get the package "by hand" and do the GPG check themselves.
- hellbanner 11y agoSame issue when people post GPG keys on their website. You can't verify them.
- stephenr 11y agothat only becomes applicable if you use their "manual" install steps on that security page.
- plausibility 11y agoIt's also (one of the) recommended ways to do it for Docker[1]. I've noticed a few blog posts that touch on "here's how to use Docker for X" suggest piping it straight into `sudo sh` without so much as looking at what's going to be run first. Sigh. [1] http://get.docker.io/ http://get.docker.io/
- deleted 11y ago[deleted]