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.
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:
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.
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.
"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.
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.
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
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.
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?
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.
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.