[ANN] Rails 2.3.12 has been released!

Hi everyone! I’ve released rails version 2.3.12.

Security issues!

There are security issues in the rails_xss plugin, and we’ve fixed them with this release. Please make sure to upgrade your rails_xss plugin.

Please see here for more details about the security issue.

CHANGES

The main changes in this release are fixing compatibility issues with Rubygems 1.8.5.

You can view the complete list of changes here.

SUPPORT!

I want to briefly mention provided support for the 2.3.x series. This branch is in security-maintenance mode. We will release it when there are problems like “the sky is falling”, or major security issues. It’s time for us to focus on pushing Rails forward!

Potential XSS Vulnerability in Ruby on Rails Applications

The XSS prevention support in recent versions Ruby on Rails allows some string operations which, when combined with user supplied data, may leave an ‘unsafe string’ incorrectly considered safe. It is unlikely that applications call these methods, however we are shipping new versions today which prevent their use to ensure they’re not called unintentionally.

How the XSS Prevention Works

When strings are rendered to the client, if the string is not marked as “html safe”, the string will be automatically escaped and marked as “html safe”. Some helper methods automatically return strings already marked as safe.

For example:

<%= link_to('hello world', @user) %>

The link_to method will return a string marked as html safe. Since link_to returns an “html safe” string (also known as a safe buffer), the text will be output directly, meaning the user sees a link tag rather than escaped HTML.

The Problem

Safe buffers are allowed to be mutated in place via methods like sub!. These methods can add unsafe strings to a safe buffer, and the safe buffer will continue to be marked safe.

An example problem would be something like this:

<%= link_to('hello world', @user).sub!(/hello/, params[:xss])  %>

In the above example, an untrusted string (params[:xss]) is added to the safe buffer returned by link_to, and the untrusted content is successfully sent to the client without being escaped. To prevent this from happening sub! and other similar methods will now raise an exception when they are called on a safe buffer.

In addition to the in-place versions, some of the versions of these methods which return a copy of the string will incorrectly mark strings as safe. For example:

<%= link_to('hello world', @user).sub(/hello/, params[:xss]) %>

The new versions will now ensure that all strings returned by these methods on safe buffers are marked unsafe.

Affected versions

This problem affects all versions of rails: 3.1.0.rc1, 3.0.7, and 2.3.11.

The Solution

Any methods that mutate the safe buffer without escaping input will now raise an exception.

If you need to modify a safe buffer, cast it to a Ruby string first by calling the to_str method:

<%= link_to('hello world', @user).to_str.sub!(/hello/, params[:xss]) %>

Upgrading

This problem is fixed in Rails 3.1.0.rc2, 3.0.8, and 2.3.12 (with rails_xss). If for some reason you cannot upgrade your Rails installation, please apply these patches:

Thanks

Thanks to Bruno Michel of LinuxFr.org and Brett Valantine who each independently reported the issue to us.

News from the Documentation Front

New Configuration Guide

Rails 3.1 will come with a new comprehensive guide about configuring Rails applications written by Ryan Bigg (@ryanbigg). The current draft is already available in the edge guides.

Rails Documentation Team

The documentation team, which was created some three years ago and consisted of Pratik Naik (@lifo), Mike Gunderloy (@MikeG1), and me, played a key role at bootstrapping docrails. Together with lots of API contributors and guides authors. Kudos to Pratik and Mike, their effort was outstanding and gave a definitive push to this aspect of the project.

After all these years, documentation maintenance happens regularly in master. Because of that, we are no longer going to have a separate documentation team. The same way we do not have a separate testing team. Tests and docs are an integral part of Ruby on Rails and complete patches have or should have proper tests and docs coverage.

Rails Guides Reviewers

Reviewing guides needs a special profile and dedication that has its own standards and pace. There’s going to be a team of guides reviewers that will take care of new material. I am very glad to announce that Vijay Dev (@vijay_dev) is going to be the first member of this team. Vijay has done an awesome work in docrails in the last months. Welcome aboard :).

Next Steps

The Rails documentation has improved a lot in the last years, it has more content, and it has better editorial quality. But there’s still a lot to do. Here are some ideas to work on:

  • A new documentation generator that evaluates the source tree and introspects to generate the API, mixed with a parser to extract documentation snippets.

  • Methods in the API have a link that toggles the visibility of their source code. Wouldn’t it be awesome if there was a toggler that disclosed their tests?

  • Test coverage for the guides.

  • What about a gorgeus template design?

If you’d like to hack on any of them please go ahead!

[ANN] Rails 3.0.8.rc3 (third time is the charm!)

Hey everybody! I’ve pushed Rails 3.0.8.rc3.

Hopefully this release candidate takes care of all the outstanding issues remaining. To see what has changed between 3.0.8.rc2 and 3.0.8.rc3, check out this link on github. If no regressions are found, I will release the final version 72 hours from now (Thursday, June 2nd around 1pm). Please let us know if this release candidate causes any regressions from the 3.0.7 version.

I’m still getting over my cold, so I promise that next release I will return to my normal level of excitement! ;-)

[ANN] Rails 3.0.8.rc2

Hey folks! I’ve pushed 3.0.8.rc2.

I want to give a big thanks to Philip Arndt and Robert Pankowecki for reporting regressions in 3.0.8.rc1! We’ve fixed the regressions, so I pushed an rc2.

To see the diffs for this rc, check out the commit list on github.

Since we’ve released a new release candidate, I’ll target the final release for June 1. If you find regressions between v3.0.7 and v3.0.8.rc2, please let me know and we’ll do another rc!

Thanks everyone!

$ curl 'http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/383777' | ruby -n -e'print $_.gsub(/rc1/, "rc2")'

[ANN] Rails 3.0.8.rc1

ZOMG HI EVERYBODY!!!! HAPPY WEDNESDAY (UTC-7).

I am EXCITED, PLEASED, and even MORE EXCITED to announce the release of the Rails 3.0.8 released candidate NUMBER ONE!

OMG RELEASE CANDIDATE. WHAT DOES IT MEAN?

This is a release candidate! It means that we (the rails core team) are asking you (our lovely users) to test out the code that we’d like to release!

This is your chance to VETO our release of Rails 3.0.8 final!

VETO?? WHY WOULD I DO THAT?

Well you see, dear public, let me explain. In order to bring you this latest and greatest released of rails, we’ve made bug fixes and changed codes. Unfortunately, that means that we may have inadvertently broken your application. We don’t want to break your application, we want to fix bugs!

This is your chance to try our the release candidate and let us know if we’ve broken your application!

HOW DO I TEST YOUR WONDERFUL AND AMAZING RELEASE CANDIDATE?

Very simple! If you’re using bundler, just update your Gemfile to point at rails version ‘3.0.8.rc1’. Then do a bundle update, and you’re off to the races! Make sure your application behaves normally, all your tests pass, etc.

I think I’ve found a boog! How do I veto???

It’s easy, breezy, beautiful, to veto! Just reply to this on the rails-core mailing list, and let us know what went wrong! We’ll fix the problem and cut another release candidate.

Make sure to check that your failure does not occur on Rails 3.0.7, but does occur on the release candidate. If the failure is also on 3.0.7, we still want to know! It just won’t block our release.

TELLME THE CHANGES YOU’VE MADE!

Ok, just calm down. For now, go check out this link on github.

Or go check out the CHANGELOG files in each project. When we release the final, I’ll add the changelog to the announce email.

WHEN WILL THE FINAL RELEASE BE??? TELL ME NOW!!!

Typically we release the final version 72 hours after the release candidate. But this weekend is a holiday, so I don’t feel like doing a release this weekend. Instead, I will target the final to be released on May 31st.

If we find show stopping bugs, we’ll release another RC and the 72hour counter will reset!

WHY AREN’T YOU RELEASING ON THE WEEKEND? COMMON, BRO.

What?!?! Why aren’t you releasing on the weekend??? I’m going to be making sausage. :-P

Thanks everybody!!!!

<3 <3 <3 <3 <3 <3

Rails 3.1: Release candidate

As I promised at RailsConf, we’re finally good to go on the Rails 3.1: Release Candidate. This is a fantastically exciting release. We have three new star features and an even greater number of just awesome improvements. First the stars:

The Asset Pipeline
The star feature of 3.1 is the asset pipeline powered by Sprockets 2.0. It makes CSS and JavaScript first-class code citizens and enables proper organization, including use in plugins and engines. See my RailsConf keynote for a full tour. This comes with SCSS as the default for stylesheets and CoffeeScript as the default for JavaScript. Much documentation is on the way for this.

HTTP Streaming
This lets the browser download your stylesheet and javascripts while the server is still generating the response. The result is noticeable faster pages. It’s opt-in and does require support from the web server as well, but the popular combo of nginx and unicorn is ready to take advantage of it. There’s a great Railscast on HTTP streaming and the API documentation is strong too.

jQuery is now the default
We’ve made jQuery the default JavaScript framework that ships with Rails, but it’s silly easy to switch back to Prototype if you fancy. It’s all bundled up in the jquery-rails and prototype-rails gems. Just depend on the one you’d like in the Gemfile and it’ll Just Work.

Other good stuff:

  • Reversible migrations: DRY migrations that know how to revert themselves. Cleaner, nicer migrations.
  • Mountable engines: Engines can now have their own routing and helper scope. They can also take advantage of the asset pipeline (more documentation on this soon). Read the story behind mountable engines (even if the asset stuff is now out of date).
  • Identity Map: It’s not enabled by default because of some important caveats that are still to be ironed out, but if you can deal with those, it’s a great way to cut down on the number of queries your app will trigger. Faster is better!
  • Prepared statements: Active Record now uses cached prepared statements, which is a big boost for PostgreSQL in all cases and a boost for MySQL on complex statements.
  • Rack::Cache on by default: This makes it possible to use HTTP caching with conditional get as a replacement for page caching (which we’ll soon factor into a plugin and remove from core).
  • Turn test-output on Ruby 1.9: Much nicer test output courtesy of the Turn gem. It’s on with new applications by default on Ruby 1.9.
  • Force SSL: It’s now easier than ever to keep your app safe with force_ssl. Either per-app or per-controller.
  • Role-based mass-assignment protection: attr_protected now accepts roles, so it’s easier do deal with admin/non-admin splits and more.
  • has_secure_password: Dead-simple BCrypt-based passwords. Now there’s no excuse not to roll your own authentication scheme.
  • Custom serializers: Serialize objects with JSON or whatever else you’d like.

You can also check out the an even longer changelog and get a video overview from Railscast.

If you’re starting a new application, it’s strongly recommended that you do so using Ruby 1.9.2. Rails will continue to support 1.8.x until Rails 4.0, but it’s considered the legacy option. Ruby 1.9.x is where the action is. Get on board and enjoy the massive speed boost.

You can install the Rails 3.1: Release Candidate with gem install rails --pre. Enjoy and report any release candidate issues on Github. We expect to release the final version in a couple of weeks if all goes well.

Rails 3.1 beta 1 released

We’ve taken our first release step towards the final version of Rails 3.1 today with the unveiling of beta 1. This is a release mostly for people who’ve already been following along with the development of Rails 3.1 and want to try a version that’s close to feature complete.

We do not yet have all the documentation ready, so it’s still a bit of a detective job to figure out how it all fits together. Thus, this is not a general release and I wont hold it against you if you’re holding out for a release candidate (coming in the next few weeks).

The tag is 3.1.0.beta1 and you can install using gem install rails --pre. Enjoy!

jQuery: New Default

In Rails 3.1 jQuery is going to be the default JavaScript library. Also, RJS has been extracted out. This post explains what that means for new applications, and what to look for while upgrading existing applications.

New Applications

Starting with Rails 3.1

rails new my_app

generates an application with jQuery.

The -j option of the generator lets you choose Prototype and Scriptaculous instead:

rails new my_app -j prototype

Such an application does not have RJS yet available though. From now on prototype-rails is needed for RJS, see below.

Upgrading Applications Using No RJS

Existing applications using no RJS should remove any references to ActionView::Base.debug_rjs in the project. Typically that means deleting

config.action_view.debug_rjs = true

from config/environments/development.rb. Other than that, upgrading should work out of the box as far as these changes is concerned.

Upgrading Applications Using RJS

Existing application using RJS should work out of the box with prototype-rails.

prototype-rails

RJS has been extracted to prototype-rails.

Applications using RJS have to add this line to their Gemfile while working against Rails master before the 3.1 release:

gem 'prototype-rails', :git => 'git://github.com/rails/prototype-rails.git'

prototype-rails is gonna be a gem when Rails 3.1 is out.

prototype-rails is the one who provides now the RJS template handler; the configuration flag ActionView::Base.debug_rjs; the ability to pass a block to link_to_function and button_to_function; the :update option of render, both in controllers and views; and the modules ActionView::Helpers::PrototypeHelper and ActionView::Helpers::ScriptaculousHelper.

Extraction has taken backwards compatibility into account as much as possible. With that goal in mind, everything is put back where it was before, either by reopening classes or modules, or via alias_method_chain when the refactor involved cutting some part of a method out, as happened with render :update.

There’s an exception: ActionView::Helpers::PrototypeHelper and ActionView::Helpers::ScriptaculousHelper are no longer ancestors of ActionView::Helpers. They are now injected into ActionView::Base and ActionView::TestCase directly.

When you include a module M into a class C, the class stores a proxy to M in its ancestor chain. After inclusion, if you add methods to M instances of C respond to them. But if you include another module N into M, the ancestor chain of C is not updated. Instances of C won’t respond to N’s methods. Although a complete dynamic method dispatch would treat both ways of augmenting M equal, that’s the way it works as of today.

By the time prototype-rails is loaded ActionView::Helpers has already been included into ActionView::Base and ActionView::TestCase, so we need to inject them directly where they are needed. Standard usage just works, but please take into account that change in case you reopened or used ActionView::Helpers assuming those ancestors.

Before release, prototype-rails is going to provide also a way to bring Prototype and Scriptaculous to any application.

One Last Detail: The xhr Test Helper

The xml_http_request/xhr test helper is a simple convenience method that sets the X\_REQUESTED\_WITH header to “XMLHttpRequest”. If the test request has no Accept header, a fixed value of

[Mime::JS, Mime::HTML, Mime::XML, 'text/xml', Mime::ALL].join(', ')

serves as default.

The Accept header in Prototype calls corresponds to that value, but in jQuery it depends on the dataType attribute. Also, in other JavaScript libraries the Accept header may behave differently. What to do with the default?

This method has been left as is. In particular, if your application uses jQuery the default Accept header in the test will be different from the Accept header sent by jQuery. That’s some vinegar: Rails encourages you to base interfaces on explicit format parameters. So, for example, best practice is to provide a /users.json endpoint, rather than a /users endpoint with a JSON representation chosen depending on the Accept header.

If you desperately need a matching Accept header in tests you are still able to pass it. And you can also write your own convenience test helpers easily, since a XHR request is just one whose X\_REQUESTED\_WITH header matches /XMLHttpRequest/i.

Try It Out!

If your application uses RJS it would be really helpful that you test it against master with prototype-rails and report any issues you may find. Thanks!

Rails 3.0.7 has been released!

Hello everyone! I’ve released Rails version 3.0.7!

I want to say thanks to Santiago for handling the release candidate gems. He’s on vacation, so I get to do the real thing.

The main change in this release is to fix a performance regression in ActiveRecord that was introduced in version 3.0.6.

Changes

For a web friendly view, check out the compare view on github.

For those that want the TL;DR of the commits, here are the pertinant CHANGELOG entries for each project:

activesupport

  • Hash.from_xml no longer loses attributes on tags containing only whitespace [André Arko]

activerecord

  • Destroying records via nested attributes works independent of reject_if LH #6006 [Durran Jordan]
  • Delegate any? and many? to Model.scoped for consistency [Andrew White]
  • Quote the ORDER BY clause in batched finds - fixes #6620 [Andrew White]
  • Change exists? so records are not instantiated - fixes #6127. This prevents after_find and after_initialize callbacks being triggered when checking for record existence. [Andrew White]
  • Fix performance bug with attribute accessors which only occurred on Ruby 1.8.7, and ensure we cache type-casted values when the column returned from the db contains non-standard chars. [Jon Leighton]
  • Fix a performance regression introduced here 86acbf1cc050c8fa8c74a10c735e467fb6fd7df8 related to read_attribute method [Stian Grytøyr]

actionmailer

  • remove AM delegating register_observer and register_interceptor to Mail [Josh Kalderimis]

Checksums

Just in case!

$ shasum *
6b96ed6cf0717e7e40b7ef9b39a70814d3928250  actionmailer-3.0.7.gem
c28009b6ce47c60553027c1ddd9c9bd2aacb2c82  actionpack-3.0.7.gem
6ee5ca84b460fff55e7dd825fc966cfbc4b36070  activemodel-3.0.7.gem
25ff07f49129ccd405c95047b41e6717e95f9471  activerecord-3.0.7.gem
a4adde3ad82017d8925e99733d1cd288b1474c39  activeresource-3.0.7.gem
d1a0192fd9da869caee79be66a5915633eda291f  activesupport-3.0.7.gem
04aa110f50d2ea9b8434526faff57ab2e249495e  rails-3.0.7.gem
9430747274afa4fac2c37ae05a39f9cb79680e16  railties-3.0.7.gem

Have a great week everyone!

<3 <3 <3 <3 <3