It's great that manual compilation works for Matz. And his great work notwithstanding, it has little to do with the general user.
As an occasional Ruby programmer, and frequent Ruby-based utility user, I do not want to compile and install Ruby or Ruby modules myself. If we go down that road, why don't we compile everything from Python to GStreamer ourselves (since they all have modules/plugins/...)?
To the general user (as opposed to full-time Ruby programmer), Ruby and Ruby modules are just dependencies to the application they want to use, and installation should be automatic. One can only hope that the Ruby community understands this, and makes it easy for distributors to package their software.
As an occasional Ruby programmer, and frequent Ruby-based utility user, I do not want to compile and install Ruby or Ruby modules myself.
I empathize with you, I am the most non-techie programmer I know and I dislike compiling things from scratch. (deep breath) HOWEVER...
The culture of programming on star-nix platforms is built around building stuff yourself. It's great when there is some form of Ruby pre-installed by default on OSX, for example, but every serious Ruby programmer must go out and compile the latest version(s) at some point or another.
I wish there was an easier way, and I applaud the folks building package managers, rvm, and so forth. But underneath all these tools is a compiler, that's the architecture of star-nix paltforms and programming for them. Everyone needs to understand what their abstractions are hiding.
The only way you can make an informed choice about the convenience and security implications of choosing to use rvm or some such is if you understand how to compile Ruby for yourself on your platform.
If that isn't your bag, I will push back and ask why you're programming on a star-nix platform?
True and un-true. Yes, compiling software is at the heart of Unix programming. However, automation with regard to systems management is also at the heart of Unix programming. All these package management systems evolved to solve a very complex set of problems.
Compiling Ruby by hand is fine if you're running purpose-built VPSs, or cloud instances, or whatever the hip new phrase is, but for people who manage systems in the old world where 1 machine = 1 OS install and multiple, commingled services, it's an entirely different ballgame. Managers of these systems can't vet each and every interpreter on the system.
If someone in web integration walks through the door with a request for a Ruby interpreter to use a set of scripts for integrating the company's new website with the old back-end finance systems, the sysadmin's first stop is the stable package repository for their chosen distribution. Compiling by hand is yet another exception that must be tracked.
In enterprise environments were IT staff are outnumbered by a couple of orders of magnitude, exceptions are the proverbial "death of a thousand cuts". That is why failure to play ball with package management systems like apt is a poor choice. It will hurt the adoption of Ruby in many environments.
If that isn't your bag, I will push back and ask why you're programming on a star-nix platform?
I pretty much disagree with your whole point. I mostly program C, C++, and Prolog on *nix, and I rarely have to compile anything except for my own software (obviously). Debian provides nearly all libraries I'd ever use as a package.
If other people want to use my software, I can tell them to install dependencies such and such, or even provide a Debian package of my software. I don't want them to need to put the effort in reconstructing my build environment.
I dislike compiling myself because then I also have to deal with upgrading them. Sometimes building is a pain because programs have arcane build steps, or are less-secure by default. I certainly don't trust myself to compile network programs (apache etc) with the most secure options. Paradoxically, I think it's safer for me to rely on packages than to compile myself. Maybe I'm being naive. :)
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.
Just in case someone uses this as installation instructions, there's a (small but important) missing step. After installing via bash and before installing any rubies, add this to your shell's startup file:
Then open a new shell and check the output of `type rvm | head -1`. It should return "rvm is a function".
Maybe more importantly, run `rvm notes` before installing any rubies. Many operating systems will need to install various development packages first. `rvm notes` will tell you what you are likely to need for your OS.
Fair enough and a good point. I hang out in #rvm on irc though, and a reasonable number of people manage not to read the notes the installer spits out (or the docs online, which are excellent). But it's a good point, nonetheless.
I mean, apt-get install will also compile from source, if you have the right repositories enabled.
The complaint about 'compiling from source' is that you have to manage the compilation yourself, the paths, where it's installed, etc. rvm addresses this problem.
I mean, apt-get install will also compile from source, if you have the right repositories enabled.
No, it doesn't. It will install binary packages that are signed. That means that if I install a package on my local desktop and a server in New York, it will exactly be the same. No matter if there are differences in the environment or configuration. Besides that I want every system file tracked by one package management system (for ease of administration), and easy security updates.
Another important benefit of using binary Debian packages is that you get the testing that preceded progressing of the package into Debian testing for free. Constrast that with a gem that happened to be updated just 30 minutes ago, with no testing in the particular configuration where it is used.
We have been burnt badly in the past by out-of-distro 'package management' before (little testing, incompatible versions, failing builds, etc.), that I stopped using non-distribution packages mostly.
Unless you are referring to kernel module packages that use DKMS (I guess not) or 'apt-get source' which retrieves the source of a package in conjunction with '--compile'. But that's not a very common use of APT.
I was thinking of apt-get source, actually. It's been two years or so since I've used Debian, since our worldviews are incompatible.
> Constrast that with a gem that happened to be updated just 30 minutes ago, with no testing in the particular configuration where it is used.
This doesn't really happen, though. Bundler makes sure that you have the exact same versions of gems that you used everywhere else, and if anyone's got the automated testing thing down, it's Rubists. You won't get the 30 minute old version unless you want to.
You won't get the 30 minute old version unless you want to.
Frankly, I do not want to care. I want the latest stable version with security fixes. With a busy work schedule, I do not have time to maintain a stable set of Ruby modules. It's a matter of economics: you could let every user find out a stable combination of modules, and everyone will end up doing a lot of duplicate work. Or the distributor could do it, saving 95% of the users who do not have specific needs many hours of work. And as a bonus, we all get the collaborative testing and bug reporting that was done in Debian Unstable and Debian Testing.
This approach works well for many interpreters and compilers in Debian (as someone else pointed out, Python is well-integrated in Ubuntu and Debian).
I think we're talking around each other, which is what this whole issue is about.
I'm coming from the perspective of a ruby application developer. I've got my server, it's all set up, I type 'cap deploy' and it takes care of everything, including my dependancies. I don't need to 'figure out what works,' because my application is developed locally, I already have all of the versions worked out, because it's what I was building the software with. This situation is a happy one. Everything's good. Yes, I'm technically using two package managers, but I don't really care: it's all been abstracted away, and everything _actually works_.
If I try to do things through apt, all of the gems simply aren't there. Or older versions of things, which break because my code was written with newer ones. It's simply a non-starter.
However, from a sysadmin standpoint, where you're keeping Ruby on a system for a certain reason, the use case is totally different.
The real problem happens when people who use Ubuntu because they're new to Linux want to start with Rails, and it has to be explained that almost nothing they read will actually work properly. They're the real people who suffer out of all of this, not you and I.
I've heard this before, but I almost wonder if it's the exception that proves the rule. That is, the rule is: your OS is not likely to provide up-to-date development library packages (or interpreters for that matter) for your scripting language of choice. As a developer, you will need to get and build stuff by hand, you will need to manage a complex set of changing load paths, you will need lots of coffee and help. You will come to rely on and love tools outside of the normal distribution tool-chain.
I don't do Python, but this rule has proven to be true for me for Perl and Ruby, on systems including OSX, OpenBSD and Debian. I always end up having to get cpanm to install Perl modules, Perlbrew to install newer (or variant) Perl interpreters and ditto for Ruby, rvm and company. (I dabble in Haskell and Lua, and it's true there too so far as I can tell. But my experiences with those languages are too limited to really say.)
I think that Python is a special case, and I honestly don't know why. Maybe they've figured out something that Perl and Ruby haven't. Maybe it's because Gnome is built using Python very heavily, and Debian ships with a default Gnome desktop and so they care more about Python. Maybe the Python team at Debian is just better staffed. I don't know, but Python is the exception here.
That's part of the complaint. The main complaint though is that it's harder to verify the source of the source because it's nonstandard for your distribution. Ideally, if you're building on a Debian derivative, anything you install comes in through apt-get, with a signed package. If you're on Red Hat, yum. And so on. RVM is not only unsigned, it brings in considerably things to do than apt-get install.
I understand the desire to stick with your distro's package management where you can (especially if you use Debian or a Debian-derived distro. APT rocks.)
However "stomping on your distro's package management" is not a fair description of what rvm does nor how it works. rvm is very well crafted to stay completely out of the way of a package manager like APT. If you use rvm normally, nothing is installed at the system level (e.g. /usr/local), much less into /usr/bin (or somewhere APT expects to manage). Everything is sandboxed in $HOME/.rvm/ nice and clean. You can remove it at simply as `rm -rf $HOME/.rvm` and a quick edit of your shell's start-up files. APT is in no way "stomped".
Hm well, I do use my distro's (ubuntu) default package manager if I'm not doing rails dev (sudo apt-get install ruby rake) but I need to easily switch between ruby versions and rails versions sometimes, so rvm makes my life easier. It lets me create "gemsets" -- it's not that I don't appreciate the package being in the repos or something :) Honestly I don't see the big deal. It's possible that a person might use the repo packages sometimes, and rvm other times. From a purely practical point of view, it seems okay.
Though, if I was able to do that with the distro's packages that'd be cool too.
Additionally, manual compilation works great for your Apple Macbook that you develop on or your podunk website that runs on one machine (the commonality here is that you have one machine), but is a nightmare for any serious deployments where you're getting millions of hits a month and have a a non-trivial number of machines to manage. The last thing you want to do is configure a manual compilation via something like puppet, chef, or cfengine.
Do you know about gem2deb ?
https://github.com/thwarted/gem2deb
'Takes a URL to a .gem or tar'ed gem and does the brute force work of converting it to a .deb package'
As an occasional Ruby programmer, and frequent Ruby-based utility user, I do not want to compile and install Ruby or Ruby modules myself. If we go down that road, why don't we compile everything from Python to GStreamer ourselves (since they all have modules/plugins/...)?
To the general user (as opposed to full-time Ruby programmer), Ruby and Ruby modules are just dependencies to the application they want to use, and installation should be automatic. One can only hope that the Ruby community understands this, and makes it easy for distributors to package their software.