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.
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.
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
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:
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.
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).
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 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.
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).
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…
Anyway, Rails is now more secure than it was yesterday, that's a great thing so yeah, thank you very much.