7 ms·

OpenBSD removes Rails from the ports tree

96 points by mben 14y ago

PommeDeTerre 14y ago
This is encouraging to see. If a given port isn't being maintained, and its security is haphazard to begin with, removing it is a very prudent course of action. While I know I can't trust Ruby and the Rails communities to do the right thing, I know with much more certainty that I can rely on the OpenBSD developers to.
- sanderjd 14y ago
  > While I know I can't trust Ruby and the Rails communities to do the right thing, I know with much more certainty that I can rely on the OpenBSD developers to. I find this intriguing. It seems to me that all of the recent Rails security issues have been communicated and patched quickly by the Ruby and Rails communities, while the ports maintained by the OpenBSD developers remained out of date and insecure, which argues for the opposite conclusion to the one you have drawn. But I don't think it's any knock on the OpenBSD developers, keeping up with patches in a fast-moving project like Rails is a losing proposition, so they're absolutely right to remove the ports and cede that maintenance responsibility.
  - PommeDeTerre 14y ago
    I see it somewhat differently. In the OpenBSD world, security isn't something that comes later via an endless stream of patches, like it does within the Ruby community. Security is done proactively in the OpenBSD realm. Care is taken to develop software that's secure from the very beginning, with security-related patches being a rare occurrence later on in the extreme case that something was accidentally overlooked. The Ruby and Ruby on Rails way is incompatible with the OpenBSD philosophy. Were Ruby, Rails and related software developed properly, there wouldn't be the need for constant hand-holding from the OpenBSD package maintainers. I don't think that the OpenBSD developers should be held responsible in any way for the negligence of the Ruby community. Getting rid of these questionable ports is a good example of the proactive approach to security taken by OpenBSD. Constantly patching low-quality software is not the correct way of dealing with the situation. Essentially getting rid of this code is the correct approach, and that's why it is good to see the OpenBSD developers following that path.
    - bradleyland 14y ago
      If you're going to follow that rationale to it's logical conclusion -- that software not adhering to the OpenBSD philosophy of security first, bar none, be excluded from ports -- then there are a lot of ports that should be removed. I'm not defending the Ruby/Rails/Rubygems community here. The problems we're facing are a result of decisions to ignore important security concerns when designing software. I'm just don't like to see people piling on. I think this is a revelation for the Ruby community. Rubygems is not just some package, it is the primary package source. This incident was as far reaching as it gets in the Ruby world. No one is claiming any different. It's also worth pointing out that the Ruby community aren't alone. This doesn't make the decisions right, it just makes it easier to understand the context in which they were made. I don't know how much progress the Python community has made, but they're facing similar challenges: http://www.davidfischer.name/2012/05/signing-and-verifying-python-packages-with-pgp/ http://www.davidfischer.name/2012/05/signing-and-verifying-p...
      - deleted 14y ago
        [deleted]
      - davidfischer 14y ago
        I realize this response is a bit late. However, it's worth mentioning that there's been quite a bit of movement here from the Python community in the past two weeks. No doubt this is a response to what happened with Ruby. A proper cert for pypi.python.org is being rolled out this week and pip should shortly have cert checking. https://github.com/pypa/pip/issues/425 https://github.com/pypa/pip/issues/425
    - ilja 14y ago
      Unmaintained ports are not constant hand-holding.
      - PommeDeTerre 14y ago
        Constantly having to patch, re-test and update ports just because some Rubyists failed to develop their software responsibly is constant hand-holding.
- byroot 14y ago
  I see your numerous FUD posts about Ruby, Javascript & others since a few weeks now, and I'm curious: What is your magical langage / technology that never had any security holes, nor any misconception ?
  - zzzeek 14y ago
    The choice of "security as an afterthought" and "never had any security holes ever" is a false choice between two extremes that don't actually exist (well, at least the second). The poster is referring to two very different approaches to software security. OpenBSD's approach is considered to be the most uncompromising in the industry, and goes further than probably most of us would prefer to go, but nonetheless serves as a good example of what's possible. You can read about it here: http://www.openbsd.org/security.html http://www.openbsd.org/security.html and there's also some good papers/presentations here: http://www.openbsd.org/papers/ http://www.openbsd.org/papers/ .
    - wmoxam 14y ago
      I love openbsd but even their proactive approach hasn't made them immune to remote exploits
      - mpyne 14y ago
        It's not about total and complete prevention, it's about reduction of risk. Your logic taken to its logical conclusion would argue against practically any risk mitigation measures at all. For instance, even SSL/TLS have not been immune to exploits.
      - martinced 14y ago
        Logical fallacy: "Fallacy of gray". http://lesswrong.com/lw/mm/the_fallacy_of_gray/ http://lesswrong.com/lw/mm/the_fallacy_of_gray/
  - static_typed 14y ago
    I think he was actually pointing out a difference in approaches. OpenBSD tend to take the conservative line, the Ruby crowd seem to take the front-door open with Yaml parsers blazing ready to run arbitrary code line. I am sure it is possible to write conservative, stable, secure frameworks and tools in Ruby, but it is rather telling that we don't.
- klochner 14y ago
  They made a reasoned decision based on: - gems shouldn't be installed via ports in the first place - the ports are not being maintained by BSD - the gems/ports in question would need to be patched You turned that into "rails sux, BSD rules." Please stop.
tedunangst 14y ago
Fun fact: January 11 was three weeks ago.
SEJeff 14y ago
I'm curious how many people run RoR on OBSD web servers. I suspect it exists, but very rarely
- protomyth 14y ago
  I did for a while, but as the patch suggests, it is probably a better idea just to install using gem. There is really no need to have rails in the ports as it doesn't require any special compilation to run on OpenBSD.
  - jzwinck 14y ago
    Ironic to see this suggestion when this post is immediately below one on the front page saying rubygems are not safe to install. It would be too bad if the security savvy BSD folks pushed their users into a worse situation by using gem.
    - jonknee 14y ago
      The situation currently is an unmaintained and guaranteed insecure package, so I don't think having users rely on something else will make it worse. > These ports haven't been maintained and have been subject to numerous security issues over the past couple years (including a very critical one that made the news this week)
    - PommeDeTerre 14y ago
      Removing some insecure and/or untrustworthy code in no way forces any OpenBSD user to use other insecure and/or untrustworthy code. I suspect that most responsible OpenBSD users with Ruby or Ruby on Rails code would likely already be looking at non-Ruby alternatives.
    - byroot 14y ago
      It's not the role of OpenBSD or any other distribution to provide those gems. I don't know anyone that rely on system packaging to get gems or eggs or CPAN module. And it would be silly because you can't run an arbitrary ruby/python app with and arbitrary version of gems. And IHMO Debian should take the same decision and stop packaging gems and eggs.
wildchild 14y ago
Wise decision. Ruby has it's own package system. I believe every developer using rvm/rbenv for managing ruby versions. Rails should be installed using rubygems. I always cry seeing pretty outdated rails packages in distributives. I don't care.
- whalesalad 14y ago
  Yep. I don't know why anyone would want to install something like Rails, Django etc... via their distribution or OS's built-in package management system. I think it's silly actually. Ruby has rubygems, Python has pip, Perl has cpan...
  - wmoxam 14y ago
    It makes sense from the perspective of it being a dependency of some end user software such as Typo or Redmine
    - dlisboa 14y ago
      I've been messing around with FreeBSD for a few days and it has RubyGems set up very conveniently. Root installed packages (like the ones from ports) would already be attended through the root installed RubyGem. Aside from OpenBSD which has their security procedures for installed software it doesn't seem like any ports distro really need to have copies of gems in their package tree if the RubyGems package is set up correctly. They could delegate that function to RubyGems, it'd be transparent to the user. Some package managers go down a more drastic route and simply tell the user to install the dependency through the correct package manager (Homebrew does that with Node, top of my mind). Users can still do it locally with rbenv/rvm/chruby if they want, it doesn't change much. The bigger I'd think is that they don't want to rely on external package managers for the stability of their system. Which is a very valid reason, if RubyGems is out you can't install certain ports. Or worse, the gems aren't safe. The system is then self-contained and tested, proven to work with the provided copies of gems. But as a simple dependency resolution perspective I don't see it being the case.
electic 14y ago
If I am reading this right, this title is wrong. They are talking about dependencies.
- homosaur 14y ago
  Rails is almost entirely a wrapper for these components like ActiveModel and Sprockets and such. You can use them apart from Rails but that's why they are all on the ports tree. It's probably the only thing that uses them.
  - steveklabnik 14y ago
    > It's probably the only thing that uses them. This is very much not true for many of the components. I have a few gems that rely on ActiveSupport and ActiveModel, Sprockets has integration with other frameworks, etc. That said, you're right, the 'rails' gem is really a meta-gem that installs all the right versions of the other ones.
    - homosaur 14y ago
      Yeah but are those other gems in the OpenBSD ports tree? The point is not that they are not used for other things but that they are probably not used in OpenBSD
      - steveklabnik 14y ago
        Ahhh probably not. Good point.
inopinatus 14y ago
I'd like to take this opportunity to highlight BSDPAN, which is how FreeBSD integrates her own package database with Perl's native module installation. Since 99% of package management is just files on a filesystem and a bit of dependency analysis, for the purposes of easing installation, permitting bidirectional awareness of state, and alerting administrators to security updates. I would commend any OS that has the smarts to hook into the package ecosystems of her guests. RubyGems, CPAN, npm, PEAR, PyPI into APT, RPM and what have you. Wouldn't it be great if. Here's an edge case, though. In the specific world of both Ruby and her fat offspring Rails, the proliferation of versions (and the widespread separation of sysadmins from developers) means that in practice many Ruby applications have the runtime language binaries and package dependencies installed in app-specific or personal home directories, via the likes of rvm. Stick that in your package management pipe and solve it.
- igravious 14y ago
  I know this is a bit of a me too post but this is something I have thought should exist for years now. Another benefit this would provide would be that you'd only have to learn one set of incantations rather than forgetting and looking up whatever subsystem it is you're messing with. For the life of me I don't know why this does not exist yet. I have such a desire for it that I thought long and hard about building something like this myself but balked at the prospect, for yea it is daunting. There are others as well: LaTeX (TeXLive) has a package system too, and I am sure there are lots more.
  - inopinatus 14y ago
    There are workflow issues to generalising the case. In particular, since this is a devops issue any such solution has to be based on satisfying the needs of developers (e.g. ease of deployment, version specificity), and the needs of admins (ease of patching & audit, dependency management) across a wide variety of packaging mechanisms for both base OS and many language-specific ecosystems. It's no surprise to me that the unit of deployment, for many sites, is becoming the virtual machine template. Since you don't even need to bother maintaining it; just keep your data separate from your code, rebuild the image when necessary with latest libs & pkgs, and throw away old ones. This is how many PaaS providers are doing things.

96 points by mben 14y ago

This is encouraging to see. If a given port isn't being maintained, and its security is haphazard to begin with, removing it is a very prudent course of action. While I know I can't trust Ruby and the Rails communities to do the right thing, I know with much more certainty that I can rely on the OpenBSD developers to.

sanderjd 14y ago
> While I know I can't trust Ruby and the Rails communities to do the right thing, I know with much more certainty that I can rely on the OpenBSD developers to. I find this intriguing. It seems to me that all of the recent Rails security issues have been communicated and patched quickly by the Ruby and Rails communities, while the ports maintained by the OpenBSD developers remained out of date and insecure, which argues for the opposite conclusion to the one you have drawn. But I don't think it's any knock on the OpenBSD developers, keeping up with patches in a fast-moving project like Rails is a losing proposition, so they're absolutely right to remove the ports and cede that maintenance responsibility.
- PommeDeTerre 14y ago
  I see it somewhat differently. In the OpenBSD world, security isn't something that comes later via an endless stream of patches, like it does within the Ruby community. Security is done proactively in the OpenBSD realm. Care is taken to develop software that's secure from the very beginning, with security-related patches being a rare occurrence later on in the extreme case that something was accidentally overlooked. The Ruby and Ruby on Rails way is incompatible with the OpenBSD philosophy. Were Ruby, Rails and related software developed properly, there wouldn't be the need for constant hand-holding from the OpenBSD package maintainers. I don't think that the OpenBSD developers should be held responsible in any way for the negligence of the Ruby community. Getting rid of these questionable ports is a good example of the proactive approach to security taken by OpenBSD. Constantly patching low-quality software is not the correct way of dealing with the situation. Essentially getting rid of this code is the correct approach, and that's why it is good to see the OpenBSD developers following that path.
  - bradleyland 14y ago
    If you're going to follow that rationale to it's logical conclusion -- that software not adhering to the OpenBSD philosophy of security first, bar none, be excluded from ports -- then there are a lot of ports that should be removed. I'm not defending the Ruby/Rails/Rubygems community here. The problems we're facing are a result of decisions to ignore important security concerns when designing software. I'm just don't like to see people piling on. I think this is a revelation for the Ruby community. Rubygems is not just some package, it is the primary package source. This incident was as far reaching as it gets in the Ruby world. No one is claiming any different. It's also worth pointing out that the Ruby community aren't alone. This doesn't make the decisions right, it just makes it easier to understand the context in which they were made. I don't know how much progress the Python community has made, but they're facing similar challenges: http://www.davidfischer.name/2012/05/signing-and-verifying-python-packages-with-pgp/ http://www.davidfischer.name/2012/05/signing-and-verifying-p...
    - deleted 14y ago
      [deleted]
    - davidfischer 14y ago
      I realize this response is a bit late. However, it's worth mentioning that there's been quite a bit of movement here from the Python community in the past two weeks. No doubt this is a response to what happened with Ruby. A proper cert for pypi.python.org is being rolled out this week and pip should shortly have cert checking. https://github.com/pypa/pip/issues/425 https://github.com/pypa/pip/issues/425
  - ilja 14y ago
    Unmaintained ports are not constant hand-holding.
    - PommeDeTerre 14y ago
      Constantly having to patch, re-test and update ports just because some Rubyists failed to develop their software responsibly is constant hand-holding.
byroot 14y ago
I see your numerous FUD posts about Ruby, Javascript & others since a few weeks now, and I'm curious: What is your magical langage / technology that never had any security holes, nor any misconception ?
- zzzeek 14y ago
  The choice of "security as an afterthought" and "never had any security holes ever" is a false choice between two extremes that don't actually exist (well, at least the second). The poster is referring to two very different approaches to software security. OpenBSD's approach is considered to be the most uncompromising in the industry, and goes further than probably most of us would prefer to go, but nonetheless serves as a good example of what's possible. You can read about it here: http://www.openbsd.org/security.html http://www.openbsd.org/security.html and there's also some good papers/presentations here: http://www.openbsd.org/papers/ http://www.openbsd.org/papers/ .
  - wmoxam 14y ago
    I love openbsd but even their proactive approach hasn't made them immune to remote exploits
    - mpyne 14y ago
      It's not about total and complete prevention, it's about reduction of risk. Your logic taken to its logical conclusion would argue against practically any risk mitigation measures at all. For instance, even SSL/TLS have not been immune to exploits.
    - martinced 14y ago
      Logical fallacy: "Fallacy of gray". http://lesswrong.com/lw/mm/the_fallacy_of_gray/ http://lesswrong.com/lw/mm/the_fallacy_of_gray/
- static_typed 14y ago
  I think he was actually pointing out a difference in approaches. OpenBSD tend to take the conservative line, the Ruby crowd seem to take the front-door open with Yaml parsers blazing ready to run arbitrary code line. I am sure it is possible to write conservative, stable, secure frameworks and tools in Ruby, but it is rather telling that we don't.
klochner 14y ago
They made a reasoned decision based on: - gems shouldn't be installed via ports in the first place - the ports are not being maintained by BSD - the gems/ports in question would need to be patched You turned that into "rails sux, BSD rules." Please stop.

tedunangst 14y ago

Fun fact: January 11 was three weeks ago.

SEJeff 14y ago

I'm curious how many people run RoR on OBSD web servers. I suspect it exists, but very rarely

protomyth 14y ago
I did for a while, but as the patch suggests, it is probably a better idea just to install using gem. There is really no need to have rails in the ports as it doesn't require any special compilation to run on OpenBSD.
- jzwinck 14y ago
  Ironic to see this suggestion when this post is immediately below one on the front page saying rubygems are not safe to install. It would be too bad if the security savvy BSD folks pushed their users into a worse situation by using gem.
  - jonknee 14y ago
    The situation currently is an unmaintained and guaranteed insecure package, so I don't think having users rely on something else will make it worse. > These ports haven't been maintained and have been subject to numerous security issues over the past couple years (including a very critical one that made the news this week)
  - PommeDeTerre 14y ago
    Removing some insecure and/or untrustworthy code in no way forces any OpenBSD user to use other insecure and/or untrustworthy code. I suspect that most responsible OpenBSD users with Ruby or Ruby on Rails code would likely already be looking at non-Ruby alternatives.
  - byroot 14y ago
    It's not the role of OpenBSD or any other distribution to provide those gems. I don't know anyone that rely on system packaging to get gems or eggs or CPAN module. And it would be silly because you can't run an arbitrary ruby/python app with and arbitrary version of gems. And IHMO Debian should take the same decision and stop packaging gems and eggs.

wildchild 14y ago

Wise decision. Ruby has it's own package system. I believe every developer using rvm/rbenv for managing ruby versions. Rails should be installed using rubygems. I always cry seeing pretty outdated rails packages in distributives. I don't care.

whalesalad 14y ago
Yep. I don't know why anyone would want to install something like Rails, Django etc... via their distribution or OS's built-in package management system. I think it's silly actually. Ruby has rubygems, Python has pip, Perl has cpan...
- wmoxam 14y ago
  It makes sense from the perspective of it being a dependency of some end user software such as Typo or Redmine
  - dlisboa 14y ago
    I've been messing around with FreeBSD for a few days and it has RubyGems set up very conveniently. Root installed packages (like the ones from ports) would already be attended through the root installed RubyGem. Aside from OpenBSD which has their security procedures for installed software it doesn't seem like any ports distro really need to have copies of gems in their package tree if the RubyGems package is set up correctly. They could delegate that function to RubyGems, it'd be transparent to the user. Some package managers go down a more drastic route and simply tell the user to install the dependency through the correct package manager (Homebrew does that with Node, top of my mind). Users can still do it locally with rbenv/rvm/chruby if they want, it doesn't change much. The bigger I'd think is that they don't want to rely on external package managers for the stability of their system. Which is a very valid reason, if RubyGems is out you can't install certain ports. Or worse, the gems aren't safe. The system is then self-contained and tested, proven to work with the provided copies of gems. But as a simple dependency resolution perspective I don't see it being the case.

electic 14y ago

If I am reading this right, this title is wrong. They are talking about dependencies.

homosaur 14y ago
Rails is almost entirely a wrapper for these components like ActiveModel and Sprockets and such. You can use them apart from Rails but that's why they are all on the ports tree. It's probably the only thing that uses them.
- steveklabnik 14y ago
  > It's probably the only thing that uses them. This is very much not true for many of the components. I have a few gems that rely on ActiveSupport and ActiveModel, Sprockets has integration with other frameworks, etc. That said, you're right, the 'rails' gem is really a meta-gem that installs all the right versions of the other ones.
  - homosaur 14y ago
    Yeah but are those other gems in the OpenBSD ports tree? The point is not that they are not used for other things but that they are probably not used in OpenBSD
    - steveklabnik 14y ago
      Ahhh probably not. Good point.

inopinatus 14y ago

I'd like to take this opportunity to highlight BSDPAN, which is how FreeBSD integrates her own package database with Perl's native module installation. Since 99% of package management is just files on a filesystem and a bit of dependency analysis, for the purposes of easing installation, permitting bidirectional awareness of state, and alerting administrators to security updates. I would commend any OS that has the smarts to hook into the package ecosystems of her guests. RubyGems, CPAN, npm, PEAR, PyPI into APT, RPM and what have you. Wouldn't it be great if. Here's an edge case, though. In the specific world of both Ruby and her fat offspring Rails, the proliferation of versions (and the widespread separation of sysadmins from developers) means that in practice many Ruby applications have the runtime language binaries and package dependencies installed in app-specific or personal home directories, via the likes of rvm. Stick that in your package management pipe and solve it.

igravious 14y ago
I know this is a bit of a me too post but this is something I have thought should exist for years now. Another benefit this would provide would be that you'd only have to learn one set of incantations rather than forgetting and looking up whatever subsystem it is you're messing with. For the life of me I don't know why this does not exist yet. I have such a desire for it that I thought long and hard about building something like this myself but balked at the prospect, for yea it is daunting. There are others as well: LaTeX (TeXLive) has a package system too, and I am sure there are lots more.
- inopinatus 14y ago
  There are workflow issues to generalising the case. In particular, since this is a devops issue any such solution has to be based on satisfying the needs of developers (e.g. ease of deployment, version specificity), and the needs of admins (ease of patching & audit, dependency management) across a wide variety of packaging mechanisms for both base OS and many language-specific ecosystems. It's no surprise to me that the unit of deployment, for many sites, is becoming the virtual machine template. Since you don't even need to bother maintaining it; just keep your data separate from your code, rebuild the image when necessary with latest libs & pkgs, and throw away old ones. This is how many PaaS providers are doing things.