[PommeDeTerre]

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.

[klochner]

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]

> 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]

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]

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-p...

[davidfischer]

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

[eksith]

Even more than the security, the reason I use it at home is because I'm lazy and I don't want to go hopping about applying patches to lock things down. Most things take the least amount of effort to configure and, probably most importantly, things are predictable.

There's no "magic", everything must be clear, documented and open.

An old friend of mine also runs OpenBSD on his machine and I don't think he's restarted in 2 years. Granted, he's running ancient software, but it works, he's using sane configs so it's secure, although he hasn't taken his eyes off the news in case any patches are released. That's really the best you can do in the end.

As much as I feel bad for the Rails team, it may hopefully be a blessing in disguise in the end. Complacency is never a good thing.

[martinced]

"An old friend of mine also runs OpenBSD on his machine and I don't think he's restarted in 2 years"

I regularly reach 6 months of uptime on my Debian desktop and I've got a Linux server which reaches 4-digits days of uptime.

I only reboot when I need to physically move the machine or when a remote-exploit affecting my setup is discovered.

OpenBSD takes this even further and more power to them. My "todo list" since a very long time is to install a firewall running OpenBSD. I should really take the time to do this.

[jdhendrickson]

May I recommend PFSense rather than OpenBSD proper, all the power of PF wrapped up in a gui that lends itself directly to firewall configuration. I really enjoyed setting up CARP with it.

[mben]

PFSense is using an older and patched version of OpenBSD PF and as you said all the configuration is done using the gui. PF configuration in OpenBSD is very simple using the cli and following the official FAQ: http://www.openbsd.org/faq/pf/index.html

[inopinatus]

Since neither Ruby nor Rails are part of the OpenBSD base system, this point is largely moot. Practically the entire ports tree consists of software that was not developed with careful security from the beginning. I think yours is a straw man argument, and it is not a surprise to me that you felt the need to fling invective at the Ruby community as backup.

[static_typed]

Not sure where anyone said it was part of Base, I am sure it was generally acknowledged as a port that was falling behind, and therefore presenting a security risk if installed, and a burden to maintain, given most users fall back to Ruby Gems anyway.

It is rather sad that any story with 'ruby' in the title seems to bring out people who are quick to shout, stamp, accuse and drown out any voices that question how things are currently being done in the Ruby world.

I would question one of your points though, you said "Practically the entire ports tree consists of software that was not developed with careful security from the beginning" - I presume you sat with each and every developer of each piece of code involved to question whether security was on their mind when they sat down to design and code, or do you feel "the need to fling invective" as you mentioned earlier?

[inopinatus]

The guy above clearly applied the coding standards of the OpenBSD base system to a contributed package and used that as a basis for argument. Irrespective of how Ruby's developers do things, it is sloppy thinking.

As for going through the ports tree, your presumption is odd, of course I haven't sat with each and every developer. Perhaps you intended irony. Ho hum. But where's the invective? It is exceedingly rare for software to be written with as much security-consciousness as OpenBSD. I don't think that's a controversial statement.

[ilja]

Unmaintained ports are not constant hand-holding.

[PommeDeTerre]

Constantly having to patch, re-test and update ports just because some Rubyists failed to develop their software responsibly is constant hand-holding.

[byroot]

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]

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 and there's also some good papers/presentations here: http://www.openbsd.org/papers/ .

[wmoxam]

I love openbsd but even their proactive approach hasn't made them immune to remote exploits

[mpyne]

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]

Logical fallacy: "Fallacy of gray".

http://lesswrong.com/lw/mm/the_fallacy_of_gray/

[PommeDeTerre]

I've used a lot of different languages, libraries, frameworks, and whatnot over my career. They all have their own problems.

Some, however, have far, far more problems (and more serious problems) than others. JavaScript, Ruby and PHP are three examples of very troubled languages. The languages themselves are filled with rather stupid flaws. Their communities are toxic, and in many cases ignorant. The software written in such languages generally exhibits poor performance, poor security, poor maintainability, and various other issues.

Call it "FUD" if you want. I see it more as the expression of truths that some find painful to acknowledge. Some programming languages and their surrounding environments are much, much worse than others. I'm not going to pretend that they're good when they aren't.

[byroot]

Well since your affirmations are never argumented nor sourced, I have hard time qualifying then as "expression of truth". They are much like "immovable opinion of a troll" to me.

Again in this comment you blame Ruby/PHP/Javascript without any detail:

> poor performance, poor security, poor maintainability, and various other issues.

Hum, well ok ... compared to what ? All these properties seems relative to me. And I really don't think that a langage / platform can combine all of them. Just like a database can't be CAP or like the project triangle[0]. Engineering is all about tradeoffs.

> Their communities are toxic, and in many cases ignorant.

Hum, even better... Even from Theo de Raadt this sentence would feel arrogant to me.

Just to be clear I have no problem with you having this opinion, and I don't really want to debate about it. I just wanted to know if you had some rational behind it. Now I have my idea...

[0] http://en.wikipedia.org/wiki/Project_management_triangle

[martinced]

Logical fallacy: "Fallacy of gray".

This one many intelligent people fall for and I can't for the heck of myself understand why, so now every single time I read it I'll post this:

http://lesswrong.com/lw/mm/the_fallacy_of_gray/

I hope I'll get upvoted relentlessly until people stop making that fallacy.

[static_typed]

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.