Rails 1.1.4: Security fix without breakage

Posted by David June 30, 2006 @ 02:18 PM

The security fix from Rails 1.1.3 might have closed the hole, but it also caused breakage for people with controllers in modules. We’ve fixed that now, so Rails 1.1.4 should work for any application that also ran under 1.1.2. We apologize for the problem with 1.1.3 and encourage everyone running 1.1.x to upgrade as soon as possible to this release.

Note: Edge Rails was never affected by this security issue as it includes a rewritten routes module. So if you’re running on the latest edge, you don’t need to worry about upgrading.

Posted in Releases | 23 comments

Comments

  1. nate on 30 Jun 15:46:

    When you post a rails update, please provide a direct link.

  2. Ahmad on 30 Jun 15:51:

    gem install rails—include-dependencies

  3. Jerome on 30 Jun 16:19:

    nate: gems update ?

  4. Me on 30 Jun 16:30:

    ‘rake freeze_gems’ kills (rm -rf) my CVS directories

    Had to do: mv rails/ rails-1.1.3 cd .. rake freeze_gems cd vendor/ ls * rsync -Cav—delete rails/ rails-1.1.3/ ls * mv rails rails-1.1.4 mv rails-1.1.3 rails

    Rails, easy to develop with, hard to deploy to and maintain on the server.

  5. tgreiser on 30 Jun 16:55:

    Use caution before upgrading to 1.1.4 if you are using engines. The mixin of controllers no longer seems to work properly. Limited use of engines may not be affected but if you are overriding any engine controllers or using 2 engines that share controllers (ie: user_engine & login_engine) I suggest staying with 1.1.3 for now.

  6. ferris_wheel on 30 Jun 17:32:

    I’m a beginner and just did a “gem upgrade rails—include-dependencies” from 1.12 to 1.1.4 and am now getting “Routing Error” “Recognition failed for /...” whereas it was working with 1.1.2. What’s up?

    Thx!

  7. Anonymous on 30 Jun 20:07:

    I dig the rails model, but honestly – this is ammo for the “stick with Java” camp. If you want to replace dated development paradigm, don’t do things worse than those languages. And if you want to develop the next generation of development tools and preach that they are the next generation of development tools, FOR THE LOVE OF GOD PLEASE TEST THEM ON MORE THAN JUST YOUR MACBOOK.

  8. DHH on 30 Jun 20:33:

    ferris: Are you working with engines? Basically, it seems that if you’re working with engines, you should never upgrade to the latest version before the engine guys have verified that it works. Or made the changes necessary.

  9. CGC on 01 Jul 05:06:

    Basically every update of rails break something, even if it is a minor update.

  10. Jirka Pech on 01 Jul 16:45:

    Yes, it does. And that’s sad.

  11. Charles Oliver Nutter on 01 Jul 22:50:

    Also included in this release is a patch to fix a block syntax that prevented Rails from running in JRuby without modification. Thankfully, now the Rails scripts will run out-of-the-box on JRuby, without modification. We’re very happy about that :)

  12. Mr eel on 01 Jul 23:31:

    “FOR THE LOVE OF GOD PLEASE TEST THEM ON MORE THAN JUST YOUR MACBOOK.”

    I can appreciate the point you make about point releases breaking something, but I would like to make a couple of points.

    Firstly, everyone is fallible. Mistakes get made. The important part is that everyone is honest about it and problems get dealt with in a reasonable amount of time.

    Secondly, issues like this will generally only affect you while you’re developing, in which case I would call the inconvenience minor. You can always step back to a previous version. If this causes problems for you on a production system, you should be testing new versions of rails before upgrading. That is your responsibility. The Rails devs unfortunately can’t test absolutely everything, so being cautious is the best advice I think.

    Lastly, don’t whinge. No one likes it. I’m sure you could have made your point a little more politely than that.

  13. DHH on 02 Jul 04:02:

    It’s unfortunate that new releases some times break things. And if you care enough to help avoid that, you can. Get involved, make sure to try out the latest versions before release, help with postings to Rails-core. There are so many alternative ways to spend the energy that fuels indignation which could help. Give it a shot.

  14. Kent on 03 Jul 00:45:

    David,

    I think it would also help to notify people at least on rails-core mailing list that you are about to release a new version, so others can test it for a while.

  15. Hamza on 03 Jul 15:06:

    Hi

    I to am having problems with engines and 1.1.4. How can I go back a version of Rails to 1.1.3 ?

    Thanks

  16. DHH on 04 Jul 02:59:

    Kent, good idea. I’ll make sure to give a heads up on the Rails-core list when we’re getting closer to release next time.

  17. Max on 04 Jul 12:57:

    Hamza,

    using gems just type > gem uninstall rails and select 1.1.4

    If you haven’t installed 1.1.3 yet, tpe > gem install rails—version 1.1.3—include-dependencies

  18. CambrianJoe on 05 Jul 02:46:

    I think Rails is going to drive our website to success, I’m willing to put up with the bumps.

    Anyways, two thoughts.

    1. I don’t think an email notification is as beneficial as inherent dependencies. When installing an engine/plugin, how can we do a dependency check? I had rails 1.1.2, installed the latest login_engine, and it really, really didn’t like it. I’ll help anyway I can if someone can point me in the right direction.

    2. When my spankin’ new login_engine completely died, I really didn’t have anything in the log files telling me what was missing, not being read, etc. What’s the missing link here, and how can I help?

  19. Andrew Stone on 05 Jul 13:22:

    CambrianJoe,

    If you are using apache, look at the error log file defined in you site config file. This is where I’ve found the type of errors that you seem to be describing.

  20. Keng Onn on 06 Jul 03:24:

    After upgrading from 1.1.2 to 1.1.4, the routing for our AJAX-ed components failed (those that we created in the ‘components’ folder).

    More specifically, our AJAX-ed form (ie “form_remote_tag forms) which initially pointed to a certain controller (ie => ‘products/product_listing’”) worked properly when the page loads, BUT after submitting the form once, the re-generated AJAX form ends up pointing to ‘products/products/product_listing’ route, which obviously screwed up the page when the form is submitted the 2nd (and subsequent) time.

    This bug disappeared when I rolled back to 1.1.2. So should I wait for 1.1.5 before trying to upgrade Rails?

  21. Kevin Morwood on 14 Jul 15:49:

    Did something change in the way that XMLRPC signatures were generated between 1.1.2 and 1.1.4?

    In 1.1.2 the URL was http://my.app.com/SigServe/api

    In 1.1.4 the URL has become http://my.app.com/sig_serve

    I don’t mind the change…I just want to know if the change was intentional.

  22. Keng Onn on 24 Jul 01:52:

    Found out what went wrong – once I changed the paths from “products/product_listing” to ”/products/product_listing” (note the forward slash in front), everything worked fine again :)).

  23. softwarehackery on 26 Jul 12:41:

    xml.declare! :DOCTYPE,:logs do ?> xml.declare! :ELEMENT,:logs,’(log)’ end => “<inspect />\n<!DOCTYPE logs [\n <!ELEMENT logs \”(log)\”>\n]>\n”