Hacker News Reader

Comment by jkyle | Hacker News Reader

> 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 | bash -s stable

[1] http://rvm.io/

View on HN

It'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/

Oh 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

Also the installer is now signed via GPG.

https://rvm.io/rvm/security

But then there's a circular dependency because the GPG key is retrieved by the bash script that is wget'd.

It 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.

The 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...

Even 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.

Indeed, 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.

It 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.

Those who would go out of their way to do the GPG check are also the same people who are horrified by `curl .... | sudo bash`

Yes, 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.

Same issue when people post GPG keys on their website. You can't verify them.

that only becomes applicable if you use their "manual" install steps on that security page.

Reply on news.ycombinator.com