Updating Rails | Hacker News Reader

Updating Rails

railsapps.github.com

30 pointsDanielKehoe15 comments

I wrote the article because a Google search for "updating rails" doesn't show any helpful results. With the urgent need to update to Rails 3.2.11 because of the recently announced security vulnerability, developers need to know what to do (especially part-time and hobby developers).

I wrote a slightly different article: http://bottledup.net/2013/01/10/bundler-and-gemfile/

It focuses on Bundler and your Gemfiles so that people understand not only how to update rails, but their other gems too. Personally I don't like rvm gemsets for bundler controlled apps (like rails) and think that rvm, bundler, rubygems and so on only serve to confuse the same part-time and hobby developers.

Better advice:

make sure you have Gemfile and Gemfile.lock checked into git so you can rollback if necessary. Then type "bundle update rails".

rvm gemsets are not necessary for bundler controlled apps.

This. Gemsets seem like an unnecessary step when a specific commit (maybe a tag too?) will do the same thing.

They're not necessary, but it sure is nice to simply archive your current gemset and have at it. If the update doesn't work out, you don't have to download and recompile your old gems again. It's a convenience, nothing more, nothing less.

Not sure why you'd have to download and recompile your old gems again using plain old Bundler.

The strategy I've been using (and I think is becoming more popular) is just to install all of your gems in one big pile, and use `bundle exec` to run your app in the limited environment provided by the Gemfile.lock. So if the update doesn't work out, you just twiddle a line in your Gemfile and `bundle exec` will magically load the older version (after `bundle install`, of course, which in this case will do zero network I/O).

I have never used gemsets, but I have had `Gemfile.lock`s that stopped working because gems were yanked. Would a gemset help in this case?

Operations noob here. Honest question: How do I apply the patch file?

I've never seen one before, and I've managed to gather, via Google and Stack Overflow, how to use a git .patch (I think anyway), but I deploy on Heroku and can't directly access the source of my gems.

I already have the workarounds in place for now, but I'm very bothered that "use the patch" is a meaningless phrase to me. It seems like a useful thing to know for future scenarios.

You do not need a patch file

All you need to do is:

    update your Gemfile to the correct version of Rails
    run **bundle update rails** in the root of your directory
    then **git commit -am "update rails"** to save the files
    then **git push heroku** to update on Heroic

The Heroku email has the information for all the Rails versions - if you are running 3.1.4, then you need to update to 3.1.10, if 3.2.X then 3.2.11 is your new version - this should be a safe update. Just pick the latest number for the X.Y version that you currently have in your Gemfile.

Right. I understand that much, but entire swaths of our application become unusable when I upgrade. Chalk it up to "legacy" code from when I was first learning Rails.

Since that is fundamentally my own problem, and I have to deal with it over time and within my team's constraints, I didn't want to bore anyone with the details of why I don't just update the gem.

Thank you for the reply/help, but my question remains: Is it possible to use the these kinds of patch files on Heroku, and if so, how?

EDIT: Responding to tomfakes here since HN won't let me:

I am only going from 3.2.2 to 3.2.11. I think the breakage is query-related, and it's actually quite embarrassing how bad so much of my old code is (procedural doesn't even begin to describe it). But this is how one learns, I suppose, and now I'm very incentive to go back and refactor/fix all of it.

I'm just worried about the in-between time, and bothered that this process of "applying a patch" is a mystery to me.

It seems strange that your app is so broken with a minor version update. Are you sure you are changing just the last number in the string, and not trying to jump a full version of Rails?

My app breaks going from 3.2.8 to 3.2.9. I haven't had time to fix it yet, so I've just applied the workaround for now too.

Rails 3.2.9 contains at least two API changing merges.

  https://github.com/rails/rails/pull/7509
  https://github.com/rails/rails/pull/7661

For the specific vulnerability that came out this week, you can just add the following to an initializer or application.rb:

ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML)

This disable the XML parsing of params which introduced the bug and most people do not use. Like this you can at least be protected for now and give yourself time to test and review the upgrade to a newer version of Rails...

It's still better to use the latest version and keep up to date, but right now the priority is to make sure that your application isn't vulnerable to an attack.

To test if an application is vulnerable, you can use the following:

curl -i -H "Content-Type: application/xml" -X POST -d '<id type="yaml">--- !ruby/object:ActionController::Base
foo: 6</id>' http://example.com

If the logs show something like this then the application is vulnerable Parameters: {"id"=>#<ActionController::Base:0x007f8534fdd840 @foo=6>}

Thanks. I added the workaround on Day 1, and have tested it using the following:

http://blog.codeclimate.com/blog/2013/01/10/rails-remote-cod...

I've just had this itching question about whether or not using a cloud host (ala Heroku) is limiting my ability to use a patchfile the way I otherwise would on a dedicated host. I'm imagining a nightmare scenario of another vulnerability without such an easy workaround, requiring use of the patchfile.

I've been searching/reading constantly since my initial post and have learned about "rails:freeze:gems" and "rake gems:unpack" which I guess would serve as patchable, as long as Heroku uses them when told to.

Reply on news.ycombinator.com