7 ms·

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 program

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.

kajecounterhack 16y ago
Have you tried rvm? bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head ) rvm install 1.9.2 rvm use 1.9.2 --default which ruby EDIT thanks telemachos, add this to either zshrc (if you're using zsh) or bash_profile or equivalent [[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"
- beoba 16y ago
  Not a good solution if you dislike stomping on your distro's package management.
  - kajecounterhack 16y ago
    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.
  - telemachos 16y ago
    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".
    - steveklabnik 16y ago
      You can also rvm implode or rvm seppuku and it'll remove itself. Which I always found to be particularly funny.
- telemachos 16y ago
  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: [[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" 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. http://rvm.beginrescueend.com/rvm/install/ http://rvm.beginrescueend.com/rvm/install/
  - steveklabnik 16y ago
    One more small note: this isn't some magic you need to learn, it spits it out when you install it.
    - telemachos 16y ago
      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.
      - steveklabnik 16y ago
        Yeah, there's a reason why RTFM became a saying... I wasn't trying to criticize, I just wanted to point it out before someone said 'good luck figuring that one out.'
- joeyh 16y ago
  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.
  - steveklabnik 16y ago
    I think you're being _just a bit_ reactionary. 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.'
    - subway 16y ago
      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?
      - steveklabnik 16y ago
        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...
        vietor 16y ago
        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.
- masklinn 16y ago
  Fantastic, he says he does not want to compile Ruby and modules himself and you give him a solution doing exactly that.
  - steveklabnik 16y ago
    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.
    - danieldk 16y ago
      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.
      - steveklabnik 16y ago
        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.
thwarted 16y ago
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.
raganwald 16y ago
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?
- danieldk 16y ago
  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.
- anonymous246 16y ago
  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. :)
- bradleyland 16y ago
  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.
huitseeker 16y ago
Do you know about gem2deb ? https://github.com/thwarted/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'

kajecounterhack 16y ago

Have you tried rvm? bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head ) rvm install 1.9.2 rvm use 1.9.2 --default which ruby EDIT thanks telemachos, add this to either zshrc (if you're using zsh) or bash_profile or equivalent [[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"

beoba 16y ago
Not a good solution if you dislike stomping on your distro's package management.
- kajecounterhack 16y ago
  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.
- telemachos 16y ago
  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".
  - steveklabnik 16y ago
    You can also rvm implode or rvm seppuku and it'll remove itself. Which I always found to be particularly funny.
telemachos 16y ago
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: [[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" 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. http://rvm.beginrescueend.com/rvm/install/ http://rvm.beginrescueend.com/rvm/install/
- steveklabnik 16y ago
  One more small note: this isn't some magic you need to learn, it spits it out when you install it.
  - telemachos 16y ago
    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.
    - steveklabnik 16y ago
      Yeah, there's a reason why RTFM became a saying... I wasn't trying to criticize, I just wanted to point it out before someone said 'good luck figuring that one out.'
joeyh 16y ago
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.
- steveklabnik 16y ago
  I think you're being _just a bit_ reactionary. 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.'
  - subway 16y ago
    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?
    - steveklabnik 16y ago
      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...
      - vietor 16y ago
        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.
masklinn 16y ago
Fantastic, he says he does not want to compile Ruby and modules himself and you give him a solution doing exactly that.
- steveklabnik 16y ago
  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.
  - danieldk 16y ago
    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.
    - steveklabnik 16y ago
      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.

thwarted 16y ago

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.

raganwald 16y ago

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?

danieldk 16y ago
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.
anonymous246 16y ago
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. :)
bradleyland 16y ago
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.

huitseeker 16y ago

Do you know about gem2deb ? https://github.com/thwarted/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'