If Your Business Uses Rails 2.3 You Need To Move To A Supported Option ASAP | Hacker News Reader

If Your Business Uses Rails 2.3 You Need To Move To A Supported Option ASAP

kalzumeus.com

198 pointssteveklabnik104 comments

Feel free to ask me for elaboration if you need any, in particular if you have a CTO or other bosscritter who you need help convincing of the importance of this. It will be seriously bad news for you if you stay on unpatched 2.3 over the next several months.

It sounds like a sensible idea, and a nice thing for you to help organise.

No doubt it will get criticised :-)

As an aside, do you think there is a better way Rails could have handled this? Or (less controversially) is there a best practise you think OSS projects should maybe follow in regards to past versions?

I have approximately 10,000 reasons to personally prefer Rails continuing to support 2.3 out of the goodness of their hearts, but I don't think that satisfying my (and other users') selfish desires is necessarily "better" than not doing that. It is necessary and proper that the project have priorities, and those aren't going to be optimal for every user every time.

I am quite happy that they were really explicit about "We are dropping support for 2.3 when 4.0 lands" so that those of us who depend on 2.3 to eat had months to explore other options prior to needing them urgently. That's something that many OSS projects can and should emulate.

I have several side projects that run on 2.3. I don't have the time to upgrade them or the resources to purchase commercial support for Rails 2.3.

Your comment makes me wonder if you are aware of some undisclosed bugs that will be disclosed in the next few months, or if it's more of just a "4.0 is dropping, 2.3 support is going bye-bye" kind of thing. If the former, I'd appreciate some clarification on that point. I have no problem backporting patches myself (and in fact extensively patch libraries when needed!), but I'm wondering if there's an active-yet-undisclosed threat, or if it's just "people aren't going to do my work for me".

Can you elaborate?

I do not have, nor possess non-public knowledge about, unpublished vulnerabilities in Rails 2.3. I am just saying that my confidence in there existing one in the near term is "near total."

Did you consider this as a potential business opportunity for yourself? My reaction on reading this was that someone should be giving you either cash or equity for your roles as both an evangelist and the person who realized this was going to be needed and organized it.

Did you consider this as a potential business opportunity for yourself?

For a few minutes. It has poor alignment with my skills (I'm a fairly decent developer and can play a security researcher occasionally, but I'm a lot better at selling/marketing software than I am at hardcore framework development) and desired lifestyle (to whit, not wanting to be up at 4 AM in the morning having to work on Rails security issues -- today excepted, apparently). It also wouldn't play well with my plans to dedicate most of my business efforts to AR going forward.

It seems more like someone should be giving you either cash or equity for your roles as both an evangelist and the person who realized this was going to be needed and organized it.

I don't take money for publicity, as a matter of policy. The idea is worth about as much as the tweet it takes to describe it. The only interesting coordination problem is matching up Customer Zero with a company interested in and capable of doing the work, and that would be worth compensation, but for the fact that I was Customer Zero.

I did briefly entertain the notion of banging down a few doors and selling this (on some model like "I'll guarantee you X amount of business, in return I get a payment of $Y0k when I bring it to your door") but, meh, I'm just not that interested in doing enterprise sales for things that I don't own. Heck, I can scarcely be bothered to do it for things that I do.

This is awesome, I was really dreading the options before, and $195/mo is totally reasonable for my relatively limited needs. Thanks for finding a good company to support this.

Given all the security problems with rails lately would you still recommend rails for a green field project?

I would absolutely use Rails for new projects, specifically because these issues are being surfaced and fixed.

A framework or system with only 10 users will never have the depth of security and bug fixing coverage that a larger, well used system has.

That's not a very strong argument - the framework with 10 users is a far smaller target than the one with thousands of installs.

True, unless your site is high profile

Or someone gets bored.

Websites are targets, not frameworks - if your site is targeted, it's the same thing as having your home-brewed 1 user framework targeted, and as long as you're making money and/or storing valuable client info this can happen anytime...

Particular frameworks, CMSes, blog systems and other widely-installed web apps are targeted all the time.

When examining web server access logs, it's quite common to see hundreds of requests coming in from a single host during a short period of time, looking to see if certain exploitable framework- or app-specific pages exist.

Such scanners do appear to target certain frameworks or web apps, contrary to your suggestion that this does not happen.

I personally have been turned off from it. Not that they have security issues, everyone does, it's the time required to roll out changes basically requires not just updating a library, but updating your framework since the line between your code and the framework can be extremely blurred.

This means that if you have multiple rails sites with limited or no timely dev support you may not be readily able to upgrade your site to resolve issues.

This is why I took down my personal blog I had built in rails since I didn't want to be exposed to these issues and didn't have the time or desire to uplift the site onto more recent versions of rails.

They normally release patches and workarounds for those who can't upgrade immediately.

I wouldn't.

I'd go with something with a definitive support life and paid support if you need it.

Either that or something simple enough you can run your own fork.

Rails has a definitive support life: http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-f...

And this article is about paid support if you need it. ;)

It does but commercial offerings that we have are still supported from their implementation in 2001.

Paid support by the vendor?

If you require paid support by a vendor, you're not really using very much open source. Which is fine, but it's a very different world than mine.

I disagree with that. Paid support is arguably the most popular monetization model for open source software. Redhat is a prime example of that.

Right, hence why I said 'much.' Red Hat is big, but it's one project of many.

I don't write web software, but I can't imagine that any other framework of any kind that approaches Rails' feature breadth or popularity isn't as ridden with subtle security flaws, to say nothing of terrible, forehead-slapping boners.

ASP.NET

It's a legit choice. Not quite as feature-rich but its getting there. SignalR is leaps and bounds above anything else. IIS is easier to configure for a new admin than nginx/*icorn. And that whole pay for support thing, well it's not a novel concept in the Windows world.

I'm curious to know what you think is in Rails that isn't in asp.net.

Given the local root in Linux lately (CVE-2013-2094), would you still recommend Linux for a server OS? :P

Linux is really good about backwards compatibility, so the situation is different.

As a Drupal dev, I couldn't recommend any CMS if we go by that standard. None of them are secure forever. A security policy is what makes a CMS trustworthy, as there will always be holes.

As a guy who dislikes it (and doesn't know all that much about it), I still find Rails' security policy to be efficient and reasonable.

Typo in the first sentence of the third paragraph in "Option 5"

"... only benefit the our companies ..."

I know many folks in the Rails community wonder why anybody could still be using a years-old system.

Once this statement is no longer true, Rails will be ready for the enterprise.

Just recently my enterprise retired our Windows 3.1 environment. It was kept running to support a system that supported a system that supported dial-up VPN access for a certain subset of users. And that's not incredibly uncommon...

Once that statement is true, Rails will BE the enterprise. Don't bank on it. (And by that I mean we'll continue to release new versions that at times will be backwards incompatible and require work to upgrade to).

Already is! I've submitted talks a few times about my experiences with Rails in an enterprise environment, no luck. Anyway, We run rails since 2006, we got large and became a bank.

Numbers: 5032 models, 42 gems, 16 submodules, lots of C extensions and eventmachine servers running in threads. From our website to ATM servers, it's everything inside a single rails application. We managed to upgrade from 2.3 to 3.2 in 6 months. Already running 4 (took only a few hours). We just completed our migration from Oracle DB to Postgres.

That is wildly interesting. If you could swing it, you should write up a full post about what that your Rails app looks like after 7 years in production.

5032...models...I, whu... ONE application?!

I would never have thought that was actually possible. A write-up regarding your architecture / challenges / solutions / future plans in a blog post would be extremely interesting.

(How long does the test suite take to run!?)

This is enterprise. What test suite?

I'd like to read more about this, if you're allowed to tell.

I've been postponing writing about this for a long time, mostly because I wanted to talk at railsconf before writing a post (who am I kidding, I just procrastinate a lot), having submitted the talk for the last 3 years without getting in I'll definetly write a long post about it.

> having submitted the talk for the last 3 years without getting in

That's a shame.

If it helps any, all my talks were rejected this year too. :/

Perhaps after receiving feedback on your post, you'll find one oe two aspects that you can refine or drill deeper on and will make a great railsconf talk for next year.

I would pay to hear this talk.

Sounds like you have some interest from others here. Talk into a webcam for an hour. Sell the video.

what is your memory footprint?

I was actually surprised reading that statement given Rails' maturity. When the large AD vulnerability was announced and many people were caught in the open for a while I had assumed there were a large number of people running version n-1 Rails.

To disclaim: I submitted this story to HN because people on HN care about patio11's blog, and if someone gets internet points, might as well be me. Do not take this as an endorsement by me or anyone else on the Rails team, thanks.

Wow, the non-drama drama comment. Very slick.

I'm sorry if you thought this was 'drama,' just trying to make sure that someone doesn't think that this is officially supported by the Rails team or that I'm speaking for anyone. Frankly, I've been running around at Ruby conferences saying "If you want old versions of Rails supported, you should be paying someone to do it," and I think Rails LTS is great, in a personal capacity.

That said, since I posted this, https://twitter.com/rails/status/346671286149337088

I heard you say this in MA this past weekend. Even more impressed that you ran there to do it :).

Thank you for helping get the word out about Rails 2.3.

Ignore the haters.

You know what? That was a dumb comment for me to write. I plead "commenting while I have the flu", and you're not the first person to get an egregiously snippy comment from me over the past couple days.

I apologize. I'll be more vigilant about what I'm posting while I'm not at my best.

I'm with you on LTS, by the way; it's a great idea.

Feel better!

I'LL KILL YOU GO TO HELL

er, thanks.

Between this and your crypto-cage-match with Colin, I think that HNers should chip in and send you a whole shit-ton of Dayquil on the regular or something. Been enjoying your comments more than in recent memory. :D

Thanks, Thomas. Honestly, the last two weeks of HN or so have been so flame-bait-y and vitriolic that I just assume everyone's tensions are high, and specifically you, since you hold a minority position on the NSA issue.

That said, I do appreciate the apology, and I hope you feel better soon. <3

That's unfair. Consider, hypothetically, a case where there is publicity on a subject that a Matasano employee has specific expertise about but which is also not orthogonal to Matasano's commercial interests. You can stipulate, if it helps, that the hypothetical employee is younger or less senior in the organization. They might reasonably decide to post something about that thing on HN or Twitter, and then follow it up with an out-of-an-abundance-of-caution disclaimer to head off any trouble at the office, right? That isn't double-secret-squirrel drama seeking, that's just trying to adapt to the weirdness of life as an employed social animal in 2013, where you have an ingroup-you and a public-you and occasionally they have to be both present in a conversation at the same time at cross-purposes to each other.

Yep. That was dumb of me.

This is one of the amazing aspects of OSS that so many seem to miss. It opens up the possibility for these types of initiatives that most closed source projects will never receive once the core developers walk away.

Great idea. Hopefully great execution for those still on older versions of Rails.

I have a Rails 2.3x ecommerce app that is not our primary product but still makes us a good amount of money.

Personally, I'd like to upgrade to Rails 3.2x (and eventually 4) so I can take advantage of some newer gems. However, the task is a little daunting given we use some older authentication and file upload libraries. All that to say, if I can't get it done soon, I will definitely go the Rails LTS route.

BTW, If any Rails devs out there want a challenge and have some time, please get in touch with me.

I might be wrong but would the trick maybe be to break it down bit by bit, so for instance break off your existing file upload stuff and replace it with CarrierWave or something different. I don't know what your codebase is like but doing it that way should in theory make it more copable to slowly tick it up to rails 3+

Yeah, that's likely the best way to do it. Problem is, our image uploads now number in the high hundreds of thousands (not counting thumbnails).

The other problem is, we are short-staffed. So, if I tackle this, it takes me off other projects for 2+ weeks.

It looks like there is a fairly active Rails 3 fork of attachment_fu (what we use): https://github.com/pothoven/attachment_fu

Gotcha, there's also some information on migrating to paperclip[1] which might suit and I'm sure someone will have done similar for CarrierWave. Of course none of that helps with being short staffed.

[1]https://gist.github.com/serek/375203

The backporting involved here is non-trivial. If the past 9 months are any indication, I would expect we haven't seen the last of the serious YAML vulnerabilities yet: http://www.cvedetails.com/vulnerability-list/vendor_id-12043...

My guess is that mostly no apps depend on that idiotic YAML can parse and execute anything anybody sends us feature, so wouldn't you forward secure rails (harden it?) by replacing YAML with a parser that only parse things?

One of the few things Rails LTS adds to prior 2.3 branches is a "hardened" set of security settings that turns off rarely-used and potentially vulnerable arg-parsing code.

First of all, thanks for the nice article, Patrick!

Feel free to ask us at makandra anything you'd like to know about Rails LTS.

Previous HN thread on this, which was not quite as popular: https://news.ycombinator.com/item?id=5794632

This was a pleasure to read. I really think this is the most intelligent solution to older rails projects.

It's also an eye opening topic for all startups out there, including mine, that rely on rails -- you will need to fight to keep your applications and servers safe. I guess you could say I spend so much time building and breaking to achieve something, that the thought of long term support often slips my mind.

Still, when building I do my best to stay away from '3-in-1' gems (aka, admin-backbone-devise-api-comments-aws) that have a 0% possibility of surviving. I stick to gems that are up there in the star count on github, and try not to touch anything that has been stagnant for 6months+. Obviously this isn't a perfect solution, but I feel a bit more confident in the survival/ longevity of the application.

If you still don't accept that software is a process not a product you're going to have a bad time. With every technology stack on this planet.

“Horsepuckey. The hypothetical person saying this is a textbook pathological customer: they’re both deeply irrational (if the app’s security was worth $5 a month then the right answer is probably to shut it off and save the server cost) and likely to be far, far, far too much headache for professional Rails engineers to have to deal with. I’m glad their mail is not going to be in the same inbox as mine when I ask questions about new security issues.”

That being said, one of the good thing about open source software is competition here is possible, unlike say the end of support of WinXP.

How long do they plan on supporting this fork? Hopefully for multiple years? I didn't see it mentioned on the site.

They're contractually obligated to support it for at least a year for me, and after that commercially viable software is commercially viable software.

You've sold me on it. It is well worth the money considering the time/effort it saves.

The whole "2.3.x is not getting any more security updates" statement is disingenuous at best. While "Security Updates" might not be coming out, "Severe Security Updates" will still be released.

That combined the the "Do nothing and, with probability of 100%, get your server owned." statement makes this pretty much just a F.U.D. piece designed to trump up business for these guys, and by proxy yourself.

Please see http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-f...

"Severe Security Updates" => "After the Rails 4 release: 4.0.z, 3.2.z"

> Many of the gems/plugins which you might be using with your current application will not be compatible with Rails 3.

I'm genuinely curious what gems people are using that are not yet compatible with Rails 3, given that it was released almost three years ago. Maybe my use cases for Rails don't match the most common ones, but I have yet to run into this issue.

For Rails 4, well, that's another matter =)

I am interested in helping gems that are not Rails 4 compatible get so, so if you can point me towards some that aren't, I'll reach out to the maintainers.

Thanks! MongoMapper is at the top of my list. Hard dependency on ActiveModel 3.

Cool, I'll get in touch with them.

EDIT: Here's the status: https://github.com/jnunemaker/mongomapper/issues/493

Active Admin is getting there in a branch, but I do like to have rubygems.org gems for production apps.

I've just started using the Turkee gem, and this needs the mass-assignment gem with Rails 4 to work correctly. Since I'm new to this one, I need to spend more time with it before I can send in some pull requests to provide patches

I hear you about the branch issue. Thanks!

We're tracking Rails 4 compatibility for the major gems we use, based on a bit of skimming GitHub Issues and Pull Requests. Here are the highlights from that list:

CanCan[1] has a '2.0' branch where Rails 4 support is being worked on. It also has PR #838 open for supporting strong_parameters in the current stable 1.6 tree.

Devise[2] pushed 3.0.0.rc about a month ago with Rails 4 support.

FriendlyId[3] seems to have work in progress on their master branch.

Acts-as-taggable-on[4] states in their README that they are compatible in version 2.4.1, but there seem to be a couple open issues related to Rails 4.

edit: formatting

[1]: https://github.com/ryanb/cancan/

[2]: https://github.com/plataformatec/devise/

[3]: https://github.com/FriendlyId/friendly_id

[4]: https://github.com/mbleigh/acts-as-taggable-on

Great! I am using CanCan 1.6.7 with Rails 4, and I haven't hit anything yet. Even using strong params.

I mean this in a friendly way, but it's nice to see that it's not just Python that has issues with major version bumps.

Compass Rails could use some help: https://github.com/Compass/compass-rails

There's also some issues with Ruby 2.0 support in it and in Compass itself, if memory serves...

I'm late to the party but we have a list of some outdated gems that are still not compatible with Rails 4 (we use a long-lived branch for rails 4 compatibility that should be merged once rails 4 is released and all our dependencies are compatible).

* client_side_validations : There is an outdated rails 4 branch

* client_side_validations-simple_form : this is trickier because it also needs compatibility with the next simple_form major version. AFAIK no work is done at the moment

* active_enum : looks like simply updating the gemspec may be enough

* ransack : there is an outdated rails-4 branch, I'm not sure what the current compatibility status is

Other than that a few gems have still not released stable versions with rails 4 compatibility and only have support in a RC or even just their master branch (for instance: simple_form, database_cleaner, sass-rails)

I helped my friend upgrade a 2.x app to 3.x about a year ago, and attachment_fu wasn't compatible. The Internet seemed to be pointing to other alternatives but they required database schema migrations (no drop-in replacements).

Isn't Paperclip a drop-in? Maybe not any more, but when it first came out, it was...

I don't remember exactly, it was a while ago. I was looking at this SO thread: http://stackoverflow.com/questions/4445244/attachment-fu-or-....

Paperclip has a small migration requirement where they add metadata(file_name, content_type,etc...) about the file to the related table.

Very nice of them to have a free community version (security patches 10 days after normal release - this seems fair to me).

I could have used this a year or so ago, but I rewrote an old 2.3 Rails app in Clojure (cookingspace.com if you are curious). Now I am glad it is in Clojure though.

I had previously updated another Rails app from 2.x to 3.x and I was surprised how much trouble it was to do that.

I've got an application running Rails and my easiest path is to eliminate it entirely.

This seems pretty obvious and applies to most popular web frameworks. From a quick Google search, one can see rails 2.3 came out in 2009. That is 4 years ago - in the context of web frameworks that is quite a while.

I didn't see "Firewall that thing off from the Internet" mentioned as an option. Not all web apps are public-facing, after all.

That is a partial option, but there are ways in which it is inadequate. For example, with the January Rails vulnerabilities, dropping an IMG tag with a well-constructed URL on a site on the public internet was likely enough to suborn a developer's browser into connecting to and rooting a Rails box that was firewalled from external traffic. You still want to patch things, to prevent that and similar issues.

I think there's only one reason why a company would run Rails 2.3 in 2013: greed.

There's no way you absolutely cannot somehow find a way in about 4 years to migrate even a big code base to at least Rails 3. It's not like the migration was that complicated, there are countless guides around, a devoted community, IRC channels, consultants aplenty and even tools to hold your hand along the way.

Greed? More likely apathy and conservatism.

How about "it ain't broke"?

That's not greed.

Come on now. It's like being in a car at 80 kph in the direction of a wall and claiming that the trajectory is "just fine" a few seconds before impact. If you couldn't somehow find a way to work around the well-known end of life for Rails 2.3, then you had it coming. There's a point as a business man where you need to invest the money to make more money. In this case, fixing your code base so that it can be ready for the 4, 5 years to come.

It's more difficult in slow-moving enterprise environments. In our environment, the time from someone saying "we should do this" until it's in production can easily be 3 years.

Then, add the lifetime of use which can span even decades (depending on the application). Long-term managers and architects have seen many, many technologies and methodologies come and go, and treat claims of "you better change that system quick!" with skepticism (doesn't mean it isn't true).

Four to five years of life for an enterprise code base is a blink of an eye. If I proposed a major framework/foundation change for a four year old application, I'd be getting some unpleasant looks.

No, it's like having a car that you don't mind driving for the rest of the decade (barring any serious accident), as opposed to exchanging it for a new one every 3 years to keep up with the Joneses.

> It's not like the migration was that complicated

Really? If that was your experience, you are fortunate, but it does not match that of many.

For me, the migration of several apps from Rails 2.3 to 3 was THAT COMPLICATED. The last one I finally got finished about 9 months ago.

If someone was complaining about, say, Rails 3.0 to 3.2 -- sure, i'd agree, it's not really that complicated, just do it.

But 2.3 to 3? So very many of us found that experience to be highly unpleasant and quite that complicated. I'm glad you didn't, but your experience is not even typical, let alone universal.

It is very complicated. I upgraded one of our apps from 2.3 to 3.2 recently. The nicest thing was that the app didn't have any views and even the controller layer was slim; we had only one!

The update took around two weeks of time from two developers. The app is one of our core apps and runs very important tasks. Probably the best thing is to remove Rails completely from there.

Reply on news.ycombinator.com