5 ms·

Makes applying security patches a whole bunch of fun too!

by count 16y ago

gregwebs 16y ago
how is applying patches more difficult? I would think it is normally easier because one can RVM install a new release that has the patches applied.
- davidw 16y ago
  It's yet another way of installing software on my system. Currently I: * Use apt-get for pretty much everything. * Locally install a few project specific things. These often are installed locally, not system-wide, and have nothing to do with root. * Use rubygems. It's nice, but I don't have the same level of confidence in it regarding security that I do about Debian and Ubuntu. It seems to just give me 'updates' to gems, without much of a way of knowing which updates are security fixes and which are simply improved versions of the packages in question. RVM adds one more thing. And for each Ruby instance in there, I might have various versions of gems floating around. This does not make me happy from a security point of view.
- mechanical_fish 16y ago
  This might be true, but it does depend on how the release management is done. What else is part of that new release? Is it guaranteed to be a set of minimalist patches to fix security issues, or do the developers also take the opportunity to "tidy up" the API, or take out some of those "deprecated" features, or (god help us) introduce new functionality? [1] Much of what we see here is a dev/ops culture clash. Sysadmins like well-established system-level packaging systems like .deb and .rpm. They like them because they have well-established semantics ("this thing is obviously a security patch; that thing is probably a feature upgrade"), and they like them because these systems abstract away the need for the admin to understand the details of the release model of five or ten or a hundred different open-source ecosystems. Part of OP's complaint is that (from his perspective) the Ruby community has release semantics that he doesn't understand. Is that patch to Ruby 1.8.7 really just a "security fix"? Can it probably be safely applied to 1,000 production servers without causing downtime? --- [1] I should note: I'm not accusing Ruby developers, or any other developers, of ever having done any of these things. But these are the dark thoughts that keep engineers up at night. Especially when managing codebases built on ecosystems that they don't intimately understand.
steveklabnik 16y ago
It's still pretty easy. $ rvm install ruby-head-r29837 --patch refinements.diff For example. Bam! You're done.
- davidw 16y ago
  With one command, apt-get, I can use the same command line to install security updates for the Ubuntu versions of Ruby, Python, Java, Lua, Perl, Tcl, PHP, Erlang, Haskell, Ocaml and whatever else I happen to use. If you have to learn a separate "pretty easy" command to get security updates for the various systems on your computer, you are screwed. I think having one or two extra routes for systems that you use heavily (you're a Ruby dev or a Java dev or something like that) is probably ok, but it's still nothing I'm thrilled about.
  - steveklabnik 16y ago
    Truth. I'm not saying it's ideal, just that it's pretty easy compared to say, a source install.
  - jshen 16y ago
    but then your stuck using whatever version of ruby your distro is own. If your core development is ruby, I wouldn't leave that decision to someone else.
    - davidw 16y ago
      Actually, it's generally not that hard to take an existing Debian package and update it to the latest version of whatever software you're dealing with, if you absolutely must run a particular version. Also, Debian takes a lot of efforts to make different major versions run in parallel, like Ruby 1.8 and 1.9, Tcl 8.4 and 8.5 and so on.
      - jshen 16y ago
        that's very different than what you seemed to be implying by "with one command I can update everything". rvm is easier than creating your own deb or rpm

Makes applying security patches a whole bunch of fun too!

by count 16y ago

Makes applying security patches a whole bunch of fun too!

how is applying patches more difficult? I would think it is normally easier because one can RVM install a new release that has the patches applied.

davidw 16y ago
It's yet another way of installing software on my system. Currently I: * Use apt-get for pretty much everything. * Locally install a few project specific things. These often are installed locally, not system-wide, and have nothing to do with root. * Use rubygems. It's nice, but I don't have the same level of confidence in it regarding security that I do about Debian and Ubuntu. It seems to just give me 'updates' to gems, without much of a way of knowing which updates are security fixes and which are simply improved versions of the packages in question. RVM adds one more thing. And for each Ruby instance in there, I might have various versions of gems floating around. This does not make me happy from a security point of view.
mechanical_fish 16y ago
This might be true, but it does depend on how the release management is done. What else is part of that new release? Is it guaranteed to be a set of minimalist patches to fix security issues, or do the developers also take the opportunity to "tidy up" the API, or take out some of those "deprecated" features, or (god help us) introduce new functionality? [1] Much of what we see here is a dev/ops culture clash. Sysadmins like well-established system-level packaging systems like .deb and .rpm. They like them because they have well-established semantics ("this thing is obviously a security patch; that thing is probably a feature upgrade"), and they like them because these systems abstract away the need for the admin to understand the details of the release model of five or ten or a hundred different open-source ecosystems. Part of OP's complaint is that (from his perspective) the Ruby community has release semantics that he doesn't understand. Is that patch to Ruby 1.8.7 really just a "security fix"? Can it probably be safely applied to 1,000 production servers without causing downtime? --- [1] I should note: I'm not accusing Ruby developers, or any other developers, of ever having done any of these things. But these are the dark thoughts that keep engineers up at night. Especially when managing codebases built on ecosystems that they don't intimately understand.

steveklabnik 16y ago

It's still pretty easy. $ rvm install ruby-head-r29837 --patch refinements.diff For example. Bam! You're done.

davidw 16y ago
With one command, apt-get, I can use the same command line to install security updates for the Ubuntu versions of Ruby, Python, Java, Lua, Perl, Tcl, PHP, Erlang, Haskell, Ocaml and whatever else I happen to use. If you have to learn a separate "pretty easy" command to get security updates for the various systems on your computer, you are screwed. I think having one or two extra routes for systems that you use heavily (you're a Ruby dev or a Java dev or something like that) is probably ok, but it's still nothing I'm thrilled about.
- steveklabnik 16y ago
  Truth. I'm not saying it's ideal, just that it's pretty easy compared to say, a source install.
- jshen 16y ago
  but then your stuck using whatever version of ruby your distro is own. If your core development is ruby, I wouldn't leave that decision to someone else.
  - davidw 16y ago
    Actually, it's generally not that hard to take an existing Debian package and update it to the latest version of whatever software you're dealing with, if you absolutely must run a particular version. Also, Debian takes a lot of efforts to make different major versions run in parallel, like Ruby 1.8 and 1.9, Tcl 8.4 and 8.5 and so on.
    - jshen 16y ago
      that's very different than what you seemed to be implying by "with one command I can update everything". rvm is easier than creating your own deb or rpm