5 ms·

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.

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.

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.