New security mailing list

In light of the past days of fun and games, we’ve started a new mailing list focused entirely around security. This list will be much lower volume than the main list and be exclusively about security concerns. You can signup at the rails-security mailing list page.

UPDATE: This an announce only list. So you won’t get spammed unless it matters.

Rails 1.1.6, backports, and full disclosure

The cat is out of the bag, so here’s the full disclosure edition of the current security vulnerability. With Rails 1.1.0 through 1.1.5 (minus the short-lived 1.1.3), you can trigger the evaluation of Ruby code through the URL because of a bug in the routing code of Rails. This means that you can essentially take down a Rails process by starting something like /script/profiler, as the code will run for a long time and that process will be hung while it happens. Other URLs can even cause data loss.

We’ve backported a fix to all the affected versions for those of you that can’t update. You’ll have to apply the diff for your version:

These patches (and 1.1.6) will break applications using the 3rd party engines idea. So if you can’t upgrade because of dependencies to those, you can also add the following URL blocking while engines are being updated. Here’s how to do it with mod_rewrite under Apache:

RewriteRule ^(app|components|config|db|doc|lib|log|public|script|test|tmp|vendor)/ - [F]

Here’s how to do it under lighttpd:

url.rewrite-once = ( "^/(app|components|config|db|doc|lib|log|public|script|test|tmp|vendor)/" => "index.html" )

Unfortunately, the 1.1.5 update from yesterday only partly closed the hole (getting rid of the worst data loss trigger). After learning more about the extent of the problem, we’ve now put together a 1.1.6 release that completely closes all elements of the hole (using the same technique as the backports above).

So if you upgraded to 1.1.5 yesterday, you need to upgrade again. The approach stays the same, but since the Rubyforge gem server can be very slow at distributing gem updates, you should grab this fix straight from the Rails server:

sudo gem install rails --source --include-dependencies

If you’re running of trunk (also known as edge) using revision 4394 or later, you’re not affected by all this in any form.

We’ll follow up with more information as it becomes available. Needless to say, this is all the Rails core team is working on right now and we’ve recruited a whole band of testers to help us play this out. We’ll make sure to evaluate all the feedback that’s been coming in and develop some scar tissue a policy for dealing with security issues in the future. Thanks for your continued understanding.

We’ve also started #rails-security on Freenet for people with IRC available to get and share more information.

UPDATE: If you’re floating on gems (don’t have vendor/rails), then make sure you update RAILS_GEM_VERSION in your config/environment.rb. Otherwise you’ll still be bound to that earlier version of Rails even as you install the new gems.

UPDATE 2: Rails 1.1.6 is now available on the official gem server, so you no longer need to add the —source parameter.

Security update: Rails 1.0, 1.1.3 not affected

Good news: Rails 1.0 and prior is not affected by the latest security breach we’ve experienced. Neither is Rails 1.1.3. We’re currently investigating further just how contaminated 1.1.0, 1.1.1, 1.1.2, and 1.1.4 are. We’ll give you more updates as soon as we have the information. Our first priority has been to get a fix out, now we’ll get to the very bottom of this.

Believe you me, we take this extremely seriously. The entire core team is working on this investigation. We’ve currently made the trade-off to keep the details secret to protect people still in the process of upgrading. Once ample time for upgrading has been given and we have investigated this matter to its depth, we’ll release a complete report detailing all our findings.

Thank you for your patience and understanding. We fully understand that nothing can quite make your heart pump, as knowing there’s something wrong, but not being entirely sure what to do about it. It’s OK to vent that frustration in the comments to this post.

Rails 1.1.5: Mandatory security patch (and more)

We’re still hard at work on Rails 1.2, which features all the new dandy REST stuff and more, but a serious security concern has come to our attention that needed to be addressed sooner than the release of 1.2 would allow. So here’s Rails 1.1.5!

This is a MANDATORY upgrade for anyone not running on a very recent edge (which isn’t affected by this). If you have a public Rails site, you MUST upgrade to Rails 1.1.5. The security issue is severe and you do not want to be caught unpatched.

The issue is in fact of such a criticality that we’re not going to dig into the specifics. No need to arm would-be assalients.

So upgrade today, not tomorrow. We’ve made sure that Rails 1.1.5 is fully drop-in compatible with 1.1.4. It only includes a handful of bug fixes and no new features.

For the third time: This is not like “sure, I should be flossing my teeth”. This is “yes, I will wear my helmet as I try to go 100mph on a motorcycle through downtown in rush hour”. It’s not a suggestion, it’s a prescription. So get to it!

As always, the trick is to do “gem install rails” and then either changing config/environment.rb, if you’re bound to gems, or do “rake rails:freeze:gems” if you’re freezing gems in vendor.

UPDATE: This problem affects 0.13, 0.14, 1.0, and 1.1.×. So here’s a happy opportunity to upgrade if you still haven’t.

UPDATE 2: We’ve fixed the zlib buffer problems for people on Windows. Redownload the gem and everything should be dandy.

UPDATE 3: Regarding security through obscurity, we’ll release the full details of this issue once everyone has had a fair chance to upgrade their system. Source transparency is of little comfort if you just had your system compromised before you got a chance to apply the patch.

UPDATE 4: This problem does not affect Rails 1.0 or earlier. The only versions affected are 1.1.0, 1.1.1, 1.1.2, and 1.1.4. See security update for details.

UPDATE 5: We’ve released Rails 1.1.6 with additional fixes to the problem and created backported patches for all affected versions.

P.S.: If you run a major Rails site and for some reason are completely unable to upgrade to 1.1.5, get in touch with the core team and we’ll try to work with you on a solution.

Ruby on Rails will ship with OS X 10.5 (Leopard)

It’s finally official: Ruby on Rails will ship with the next version of OS X (see “Internet and Web”). Both server and client (on the developer DVD). We’ve been working with Apple for quite a while to make this happen and its great to finally be able to share it with the world. The love for Ruby has definitely spread inside Apple and we’ve been thrilled to see the level of interest they’ve taken to get OS X to be a premiere development and deployment platform for Rails.

The developer seed that was distributed today at WWDC contains Ruby 1.8.4 and Rails 1.1.2, but we fully expect to have Rails 1.2.x along with Mongrel, SQLite bindings, and lots of other Ruby goodies on the final gold master when it goes out in spring.

It’s been no secret that Apple is held in very high regard by the Rails community. Every single Rails Core contributer is running on Apple and the vast majority of Rails developers are too. To see Apple acknowledge this and return the favor is very rewarding.

Thanks so much to Ernest Prabhakar, Jordan Hubbard, and Dave Morin for making this happen.

Caboose Rails Documentation Drive

One of the biggest complaints with Rails is the lack of good documentation. Unfortunately, Rails is still very young, and the talented developers are either extremely busy with their jobs, or being paid to write books. The #caboose folks have started a Documentation Drive to raise $5000 to hire a professional to enhance the documentation. If you use Rails professionally, you should really consider chipping in for the benefit of all Rails developers.

Update: Thanks to some very generous contributers like FiveRuns, Fingertips, Reforge, and cdbaby, the fund is now over $13,000.

Miguel de Icaza longs for the Rails of GUI

Open source hacker extraordinaire Miguel de Icaza muses about the state of GUI APIs in light of Avalon:

I just had a realization today.

Microsoft’s Avalon is the J2EE of GUI APIs.

Its God’s way of punishing us for replacing the ten commandments with the Design Pattern fad.

We will have to wait a couple of years for the “Rails” of GUI toolkits to come into existance. In the meantime programmers will pay for their sins.

Avalon marks the end of the American Dream.

Now that’s not a happy programmer speaking.

Why you need to come to RailsConf EU

Lars Pind is voicing his concerns over the lack of enthusiasm around RailsConf Europe. I can sympathize with the fears, but allow me to iterate why you need to be at RailsConf Europe.

Rails is not an American thing! It was created by a Dane, after all. The core team musters people from Canada, Germany, and Austria. The community itself involves people from literally all over the world. RailsConf Europe should be asserting that fact and allowing us to demonstrate that there’s a viable ecosystem outside of the US.

Okay, that was the moral call to action. Now what you get out of it. RailsConf Europe will feature a host of exclusive presentations that’s not just a rehash of the US conference. We have Kathy Sierra, the star of recently concluded OSCON, gracing us with her presence. We got Jim Weirich, one of the Ruby communities best speakers, the creator of Rake and Builder, coming even though he wasn’t at the US version.

Unlike the US version, we actually have Rails core members speaking besides yours truly. The honorable Jamis Buck, the king of Capistrano, wasn’t even at RailsConf US, but will be here. Thomas Fuchs, the czar of, wasn’t at RailsConf US either, but will be here. All that on top of Marcel Molina, Dave Thomas, and myself delivering fresh speeches.

So in many ways, I see the European line-up being even stronger than the US one. That’s not to say its all a rosy dance. It’s considerably more expensive to do a conference in London than in the suburbs of Chicago, which means somewhat of a sticker shock. There’s currently less employment opportunities for Rails in Europe than in the US, so more people have to pay out of their own pocket.

But if you have the means, if you’re working professionally with Rails, you really should come. Let’s reverse the trend of US conferences bringing over an anemic, rehashed show. And let’s assert the fact that Rails is not an American invention or property. It’s a global play and a strong Europe should balance that fact.

See you at RailsConf Europe? I sure hope so! Remember, it’s September 14-15 in London. Register today.

P.S.: Americans are more than welcome too. Considering all the great exclusive speakers line up and the opportunity for a more intimate experience, I think you have a strong argument for a trip to London this September.

Russian Rails community growing fast

Yaroslav Markin wrote to inform me that the Russian Rails community is experiencing rapid growth and that they’ve now completed a translation of the entire site living at If you speak Russian and want to join the community, they already have hundreds of members in their Google Groups forum.

Do you know of any other local Rails groups making headway? Please post in the comments.