Rails 3.2.13, 3.1.12, and 2.3.18 have been released | Hacker News Reader

Rails 3.2.13, 3.1.12, and 2.3.18 have been released

weblog.rubyonrails.org

182 pointsmatt140 comments

Thanks for the fixes guys. The string of security fix releases go both ways in my head: on the one hand, I'm happy that people are actively tackling the issues as they arise, on the other hand I feel that the handling of JSON, XML and YAML looks overly complicated and that some intrinsic aspects of Rails make it even harder to keep under control (as exemplified by the half-dozen fixes over the past few weeks).

Anyway, Rails is now more secure than it was yesterday, that's a great thing so yeah, thank you very much.

Major thanks to the committers who volunteer and work very hard on these releases.

You're making Rails safer, each day, bit by bit.

Yep, kudos to tenderlove and others for putting in the work to make this framework secure by default. The changes in Rails 4 should help more with this as well (strong parameters in particular).

For those that found it obnoxious, this should remove the "Rack::File headers parameter replaces cache_control after Rack 1.5." warning you may have been seeing occasionally when booting Rails.

https://github.com/rails/rails/pull/8812

Thank you. Someone should start a blog of all the deprecation warnings Rails gives which are un-blockable and not able to be remedied by the recipient of the warnings.

can anyone comment as to ruby 2.0 and rails 3.2.13 ? Ruby 1.9.3 was still recommended for the 3.2.12 release of rails and was wondering if this was changed with this release.

edit: I actually found in the changelog : Feb 24, 2013:

Sikachu: Rails 3.2.x is now compatible with Ruby 2.0.0

thanks

Yes, please report anything that does not work on Ruby 2.0.0.

on a southwest flight and any website I visit that is not under https, has dozens of add on advertisements... makes me wish more of the web was secured... visiting the site above for security patches and seeing the hashes for those released files, reminds me that because that site isn't https someone could modify those hashes... tried downloading the files and southwest modified the binaries corrupting them... anyways good to see security releases being pushed out just wish we had better security on the delivery...

My announcement emails contain the hashes and I sign the emails. If you don't trust the blog, you can verify my signature against the announcement emails:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/...

Some of these patches involve dates that are quite old. For example, https://rubyonrails-security.googlegroups.com/attach/6c2482d... bears a timestamp of Fri, 8 Feb 2013 02:48:22 +0000.

Is this indicative of the time the vulnerability was reported?

Is it normal procedure for a patch for a security vulnerability to delayed for 36 days?

The emails are actually signed with Aaron's PGP key.

Is that a real Jason Fried comment or a troll?

Yet another freak'n patch again. Ridiculous!

At this rate, you might as well just make an official "patch Monday", so that we can expect to have weekly security bugs fixed.

Not a real Jason Fried.

Yeah, just noticed it in the other announcements. I guess I never look at the comments. Nevermind!

Anyone else getting a uninitialized constant Mocha::Integration since updating to Rails 3.2.13

I am using test unit and this seems to be related to mini test so I am not sure what is going on?

There are some issues around `uninitialized constant Mocha`: https://github.com/rails/rails/issues/9478

If that's not the same as yours, please file an issue.

Cool Thanks

I'm also seeing this issue - if you open a new issue, please link to it.

I created one - here's the link for anyone who wants it: https://github.com/rails/rails/issues/9783

Got it to work when I updated Mocha to version 0.3.13.

Anyone using Rails 4.0 in production?

Here at 500px we are using it for one of our services. No major problems, but we've had to send out a couple pull requests for side gems.

Basecamp is currently using beta1.

I know a few people who are, or at least running some projects on it. None are on fire or swearing repeatedly on Twitter, but YMMV with that.

I would be, but waiting for jruby's postgresql activerecord adapter to get updated. Doesn't work with Rails 4 yet.

There is a regression in JSON and UTF8 encoding, sometimes manifested as `invalid byte sequence in US-ASCII` or as non-escaped utf8 characters in JSON output.

If this causes problems and you want a quick fix, this gist does the job.

https://gist.github.com/sandstrom/5199891

Anybody else unable to to upgrade via bundler? I can report also seeing the following behavior: https://twitter.com/jamesgolick/status/313751280210288641

Not sure if this is a rails, bundler, or rubygems issue, at this point.

I had this issue as well. My hacky workaround was to add the version to the Gemfile, bundle update rails, remove the version from Gemfile, then bundle update rails again (to remove the hardcoded version in the lockfile).

Yuck.

Doesn't the gem command obey your Gemfile.lock? If your Gemfile.lock mandates an old version, it would install that.

Can we change the title to include "[SECURITY]" ?

I love how Jason Fried, the most self-important man in software (who can't code) is first on the list to diss the security patches. Fuck you, Jason. Learn to code. Then you can diss.

I'm quite certain it's a troll.

I do not understand, why they are overcomplicating things so much - why isn´t there just ONE rails framework? Issues with backwards compatibility vs. new features? Or what was causing this "forks"? In three years, will there be six rails versions?

If you have a large application, upgrading it will not be trivial. Suppose your company spent several months developing their app on Rails 3.1.x. Rails 3.2.x comes out and some gems you're using break when you try the upgrade. Your company still has other bugs to fix and features to produce, so they switch back to 3.1.x and just make a note to check compatibilities periodically.

The 3 versions patched are not forks. They're just different versions of Rails. In three years, they'll probably still support about 3 versions and drop support for older versions once they hit a certain age.

> In three years, they'll probably still support about 3 versions and drop support for older versions once they hit a certain age.

You can find the exact maintenance policy here: http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-f...

Spot on. We were still running 3.0 a couple of months ago when a vulnerability came out with the indication that this would be the last patch version of 3.0. We made it a point to upgrade to Rails 3.1 right then—it took about two days, which we didn't really have, but we needed to do. Since then, we've taken another 3-4 days over the last couple of months to upgrade to 3.2 (and start using features that will make a migration to 4.0 much easier).

You mind if I ask what 3.2 features will make 4.0 migration easier? I haven't kept up with the 4.0 changes

We offer strong_paramters as a gem for Rails 3.2 apps, and generally tell anyone doing greenfield development to start with it to make the transition easier, and because it's simply better.

You can check the upgrading guide for more details about what's changed, and a third party is selling an ebook that has a ton of good info as well.

steveklabnik has it spot on. We're starting to move toward strong_parameters; we've got it as a gem, but we haven't yet made the change to entirely turn off attr_accessible.

We're also starting to use verb-matchers in the routes file, but that's going to be a bit more painful to deal with…

the rails community is not big on backwards compatibility, even within minor versions.

Reply on news.ycombinator.com