OpenBSD removes Rails from the ports tree

[inopinatus]

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]

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.

[wildchild]

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.

[inopinatus]

Unfortunately this leads to language binaries & libs being distributed by the developer with the application. Sysadmins then install the whole massive hairball in /opt as a single unit and never update it until the developer provides a point release. Which never happens because the dev team has been disbanded, they're all on new projects now.

If you don't think that's a problem in the real world, you ain't seen 95% of enterprise IT.

(This problem not confined to Ruby)

[ballard]

Yes. Maintaining a canonical set of ports for frequently changing language-managed packages is like getting into a phonebook reprinting business. It would be a far better use of precious volunteer time for any given language package to push OS specific changes to that upstream rather than grow downstream collections. The *BSD community could also learn something from the arch AUP as a way to end-users to roll their own packages to make it easier to contribute and reduce their own deployed systems' entropy ... because having a singular ports collection is like SVN or top-down planned economies... they are labor-intensive to support and their decision making is distantly divorced from the intended use-case. Different from AUP would be human-sensible configuration management that doesn't require manual intervention or too much tweaking for deploying 1k+ nodes.

[whalesalad]

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

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

[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 ?

[tedunangst]

Fun fact: January 11 was three weeks ago.

[SEJeff]

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

[protomyth]

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.

[static_typed]

We did. Until a few days ago. IT Security pulled the apps after the recent critical vulns in Rails, and now this vuln with RubyGems.

Still using OpenBSD for hosting, but the apps are being ported to PHP and Python as we speak.

[electic]

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

[homosaur]

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.