Hacker News Reader

Comment by tomfakes | Hacker News Reader

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.

View on HN

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