Trac and SVN gets new powerful machine

After an extended period of troublesome Trac times, we’ve finally addressed the problem once and for all. Courtesy of TextDrive, we now have a new mega-powerful super machine dedicated to Trac and SVN. Instead of loads in the 30’es, it’s now below 1. So get all of your pending patches and tickets into the system. It now actually works.

And thanks to the move of the mailing list to Google Groups, there’s still enough power on the old server to run the wiki, the manuals site, and the weblog without slowdowns. We ruffled a few feathers during the move (some people took it harder than others, one guy wanted to hunt down and kill the responsible, eeks!), but we’re happy to report that in terms of providing breathing room for the overloaded servers, it worked like a charm.

Official Mailing List Move

Don’t worry if you see some mailing list subscriptions in your inbox, we’re simply transferring everything to Google Groups. This takes the incredible load off the Ruby on Rails server so it can focus on Trac, and gives everyone a Google-powered search engine for the archives. Atom feeds are also available if that’s your preference. Here are the new Google Groups:

Hey everyone, lets give the new rubyonrails-security list a warm welcome. It is an announcement-only list spawned from the lessons learned during the recent security incident.

By the way, it’s possible to subscribe to a Google Group without a Google account.

Streamlined: Taking admins beyond scaffolding

Justin Gehtland and Stuart Halloway has been moving along at a rapid pace on Streamlined since its unveiling at RailsConf in June. There’s now a public repository with the code available and they’ve put together a convincing screencast of its use.

I really like their approach of using separate UI classes instead of contaminating the model classes with administrative concerns. It has a great feel and look to it. Exciting to see it move forward.

Recent Rails job postings from the Job Board

We’re going to start posting a summary of recent Rails job postings from the 37signals Job Board every few weeks. All of these positions are for Rails programmers, but be sure to click through for individual listings on the additional requirements:

If you’re looking for Rails programmers, you can post a listing at the 37signals Job Board. The price is $250 for 30 days of air time.

Reloading Revamped

A few days ago I checked in a significant improvement to Rails’ dependencies and reloading code. In the past, changes to dependencies.rb have shed the blood of those courageous enough to ride edge; We’ve worked hard to prevent accidental breakage this time, but there may be some changes that could break your app.

Before you freeze edge to the prior revision, I should explain that most breakage will be extremely simple to fix. Prior to this revision, Rails would happily load files from Ruby’s standard lib via const_missing; you will now need to explicitly require such files. (Rails’ autoloading was intended as a replacement for require_dependency; its replacement of Ruby’s require is unfortunate and undesired.)

This change is not the only one that has occurred. Rails’ Reloadable module has been deprecated, and the previously independent systems of automatic loading and unloading have been brought together in a happy union.

Dependencies’ new behavior should be more reliable and less annoying. Annoyances such as the lack of module reloading have been fixed. Accidentally loading stdlib packages will no longer occur.

The actual mechanics of Dependencies are now relatively simple. Instead of using Reloadable to decide which classes to unload, Rails records which constants are loaded via const_missing. When the request is completed, each autoloaded constant is removed, leaving the process in a clean state. The actual mechanics are slightly more complex, but not inordinately so. Feel free to open dependencies.rb and peruse the code.

Hopefully the newfound simplicity of this approach will improve the transparency of Dependencies — some software is best when not noticed. If you’re running on trunk this change does cause your application to error, please do open and assign Ulysses a ticket.

Before I depart, I’d like to mention another (independent) change to dependencies: When Rails fails to find a missing constant, you will now see a fully qualified constant name in the description. For example, if a method in your User class references Acount, (rather than Account,) Rails will state that User::Acount is missing rather than ::Acount. Rest assured that Rails has looked for Acount in Object as well as User, and is merely reporting the fully qualified constant name, as Ruby’s own const_missing does.

New dedicated Trac server on the way

Our current web and mail server has been buckling under the load of the recent frenzy. Especially Trac and mailman is taking it to its knees. So we’re going to add another server. Hopefully this can be completed within the next few days. It’s going to be dedicated to just running the repository and Trac. Thanks to TextDrive for their continued support of Ruby on Rails.

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 http://gems.rubyonrails.org --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 http://gems.rubyonrails.org 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.