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.
- 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
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.
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.
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...
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.
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.
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?
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.
What is your magical langage / technology that never had any security holes, nor any misconception ?
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.
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.
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.
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