OpenBSD removes Rails from the ports tree
marc.info
marc.info
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.
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.
It's no surprise to me that the unit of deployment, for many sites, is becoming the virtual machine template. Since you don't even need to bother maintaining it; just keep your data separate from your code, rebuild the image when necessary with latest libs & pkgs, and throw away old ones. This is how many PaaS providers are doing things.
Ruby has rubygems, Python has pip, Perl has cpan...
Aside from OpenBSD which has their security procedures for installed software it doesn't seem like any ports distro really need to have copies of gems in their package tree if the RubyGems package is set up correctly. They could delegate that function to RubyGems, it'd be transparent to the user.
Some package managers go down a more drastic route and simply tell the user to install the dependency through the correct package manager (Homebrew does that with Node, top of my mind). Users can still do it locally with rbenv/rvm/chruby if they want, it doesn't change much.
The bigger I'd think is that they don't want to rely on external package managers for the stability of their system. Which is a very valid reason, if RubyGems is out you can't install certain ports. Or worse, the gems aren't safe. The system is then self-contained and tested, proven to work with the provided copies of gems.
But as a simple dependency resolution perspective I don't see it being the case.
As for security concerns: you can and should vet gems, but it won't matter if the application itself has vulnerabilities.
We don't have very many Rails app written as a packaged system for deployment. The kind you see are often SAAS apps or something to interact with people internally. They are often bespoke and written for specific needs.
Non-OS installation is a huge barrier to new users of a Ruby application. I installed Gitlab recently. Take a look at the length of the installation guide [1]. There are seven numbered steps, some of which involve multiple commands.
Upgrading from 4.0 to 4.1 was about the same complexity.
Thanks to the thoroughness of its author, the guide largely worked as advertised. But being able to install and upgrade with apt-get would have saved me hours.
[1] https://github.com/gitlabhq/gitlabhq/blob/stable/doc/install...
Aside from the fact that that's redundant, it's highly error-prone.
In places where the IT staff insists on making sure this isn't "redundant", they usually use something like fpm to create a deb or an rpm out of the gem specified by Gemfile. Which you then have to drop into a custom deb/rpm repository. On top of that, the ops staff don't know how to do that properly, so they end up with a bunch of testing and development dependencies that the Rails application doesn't need.
... or, you have the deploy process call, "bundle install"
The redundancy is in the OS packages, not in application dependencies. So it is actually better to automate such with something like Chef and Puppet. From there, I can define exactly what the application needs from the OS.
I have seen this play out in a lot of ways, devs vs. sys admin. In the past, sys admins "win" since compute resources were still scarce. We're in the age of virtual machines now and configuration automation. Applications get their own VMs, sometimes in multiple nodes. We don't have Unix high priests guarding the altar with SSH keys, hand-deploying things in secret early-morning ceremonies. We have automation to deploy for us, which means we want to make it easier for the automation to deploy, not necessarily for someone to shell in and maneuver around with hand installations.
Things being application-centric, the "right" thing is to conform to the requirements of the dev team's app, not the other way around.
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)
And if that is still a problem for 95% of the enterprise IT, I guess that's why startup tend to kick their butts out in the frontiers.
In particular, none of them yet solve the problems of client application deployment. They are also implicated in the VM sprawl many cloud users experience.
Finally, they have convinced some developers that systems administration is something they can do themselves. Experience consistently proves this wrong; I've lost count of developers out of their depth, asking for rescue from suboptimal deployment decisions and needing rescuing. Either that or they discover a penchant for systems admin as well, and thus become devops people (this is what happened to me). I've seen the latter happen most often in the ISP world; perhaps network engineers have that mindset.
Personally I foresee a stronger role for packages as an output from continuous integration pipelines (another young discipline).
I'm not sure what you mean by clients though and how that relates to VM sprawl.
It's true that some developers are convinced that sys admin is something they can do themselves. However, it goes the other way around too, that sys admins think they know what is best for the app. It's better all around if devs actually gain an understanding at the issues with sys admin, and sys admins get some development skills.
As far as the server-side goes, once nice thing about using something like Chef or Puppet is that you can create a miniature version of the production environment on the developer's laptop. You won't run into the same kind of issues when you are scaling out, but you can at least make sure that you are running everything rather than always developing things in isolation.
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.
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
- 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
> These ports haven't been maintained and have been subject to numerous security issues over the past couple years (including a very critical one that made the news this week)
I suspect that most responsible OpenBSD users with Ruby or Ruby on Rails code would likely already be looking at non-Ruby alternatives.
I don't know anyone that rely on system packaging to get gems or eggs or CPAN module. And it would be silly because you can't run an arbitrary ruby/python app with and arbitrary version of gems.
And IHMO Debian should take the same decision and stop packaging gems and eggs.
Still using OpenBSD for hosting, but the apps are being ported to PHP and Python as we speak.
Of course, given the large number of these critical issues, the business decided to pull and rewrite the apps based on input from the It Security team who described the current Ruby developer culture as being immature, ignorant of software engineering principles, unaware of secure coding, too enamoured with shiny/magic/convenience to care about longer-term implications in their design choices, thinking that constant band-aid fixes are the right way forward rather than acknowledge and fix poor design and implementation, and basically a liability for the company and it's data.
It is perfectly normal for responsible software developers, system administrators and business leaders to get angry or upset by security vulnerabilities. The impact such vulnerabilities can have on an organization is staggering.
When they're exploited, there can be huge sums of money lost. There can be serious legal ramifications. A company's reputation can be destroyed by a single incident. And those are just a few of the consequences.
Even when these vulnerabilities aren't exploited, there are still significant costs associated with fixing them, testing such fixes, deploying the fixes, and so forth.
Software is supposed to bring benefits to its users, not problems and costs. Costly problems with software will make many people angry.
Ruby, Ruby on Rails and some related software have had a very bad time lately. They have caused a lot of problems for a lot of people, and this has indeed resulted in anger and wasted monkey. Some people are making a sensible decision to look toward alternative technologies, to try to minimize their losses.
Instead of labeling such people as "trolls", the Ruby community as a whole needs to engage in some significant self-evaluation. Try to understand why people are expressing what they are, and perhaps even try to learn from what they're saying. Security is important, and the Ruby community needs to learn this fact.
He's vague and inflammatory, and avoids technical details in favor of generically insulting language ("the 'IT security' team describes ruby culture as immature"), apparently more aimed at denigrating a particular community than clarifying any issues or solutions. Much of what he writes is borderline absurd ["Rewriting in python and PHP"... really? PHP is their choice for a better-"engineered" replacement?!]
Everybody sometimes writes vague and snarky posts, but doing so repeatedly is a warning sign...
The high chance that more catastrophic rails exploits will be found in the next month (if all of the paths to YAML.load have been found, I'll eat my hat) will increase the number of people making or agreeing with statements like static_typed's. After an exploit or two have been found in February or March, people will be pointing at Rails and saying 'I told you so'.
> Ruby sucks
Ruby actually does suck. I don't like it; that's my personal opinion.
But I can't say that. All the cool startups are using it, so Ruby has become one of HN's sacred cows: There are people on here, like the parent, who take offense when someone dares have anything but the highest praise for Ruby and Rails.
I've looked at Ruby. The syntax is ugly; the language is about as bad as Perl in this regard. I've deployed Ruby applications; it's complex (although, to be fair, this is endemic to Web development). Rails is a nightmare.
A lot of HN'ers seem to like it. That's fine. But we should listen to unpopular opinions; important truths aren't always immediately universally accepted as such.
Problem: Maybe Ruby is actually the best thing since sliced bread, but I don't understand its greatness because I haven't seen the right tutorial. Solution: Write a better tutorial, improve existing ones, or point out your favorite beginning Ruby tutorials on HN or your blog.
Problem: Maybe the syntax of Ruby is really what makes me uncomfortable. Solution: A Python-to-Ruby bridge would let people like me experience the goodness of Rails without the pain of learning Ruby's extensive syntactic "innovations."
Problem: The grandparent's employer was uncomfortable with the number of security vulnerabilities recently found in Rails. Solution: Maybe having a stable branch which didn't innovate quite as fast and focused on security would make enterprise users more comfortable with Rails. Or maybe the Rails community needs more thorough vetting of new features for potential security holes, perhaps through requiring separate reviews for security and functionality before patches are officially accepted.
But if we just dismiss anyone who criticizes Ruby as a troll, how are we supposed to recognize and respond to actual problems like these? The grandparent's issues were a legitimate criticism of Ruby, and should not have been downvoted.
And you're switching to PHP? Someone should be fired for that decision.
This is very much not true for many of the components. I have a few gems that rely on ActiveSupport and ActiveModel, Sprockets has integration with other frameworks, etc.
That said, you're right, the 'rails' gem is really a meta-gem that installs all the right versions of the other ones.