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.

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.