A fix for this problem has been incorporated in a new release (Rails 2.3.4), and patches are now available for all minor versions of Rails 2.x (2.0, 2.1, 2.2 and 2.3).

Please read the full posting on the Rails Security Group for more details. For more information on the process for how Rails vulnerabilities are handled, read the Rails security process document.

(Engine Yard customers are being contacted via email about this vulnerability with instructions on how to obtain the upgrade.)

As one example, they recorded a session where someone was verbally dictating syntax and keyboard actions to their pair:

Hugh: So…
Ilya: Parenthesis. So percent, getNewArgs… [Hugh types.]
Exactly. So save off those two lines in the new method.
Hugh: Uh…
Ilya: Right…down, down, down, there we go.
Hugh: So we…
Ilya: So, percent getNewArgs equals percent args [Hugh
types this line to terminal.] Uh, I think that's it.
Hugh: This?
Ilya: Yeah, that's all we want to do. Get rid of the blank line
and close the new.

From a pair programming session revealing the perils where one person "drives" while the other "navigates." Excerpt from "The Social Dynamics of Pair Programming"

This was clearly the wrong way to go about pair-programming. "Driver" and "navigator" was turning out to be closer to "driver" and "back-seat driver" and like all experiences of back-seat driving, it could be frustrating for the driver, and generally unproductive. What we've found at Engine Yard is that it's far better to optimize the pair-programming environment not for a "driver" and "navigator," but for co-programming.

Jon Crosby and Ezra Zygmuntowicz pair-programming

A good co-programming environment should reduce the friction for any task, and has three rules:

1. Create a shared environment, where the pair can fully immerse itself in the problem at hand.
2. Make it easy for a member of the pair to 'fork' off and not interrupt flow.
3. Remove any obstacles that get in the way of completing each other's syntaxes sentences.

The Engine Yard Pair-Programming Setup

Two keyboard and mouse sets: This alone dramatically improves a pairing environment. Often we see one member of the pair 'hovering' over the keyboard -- a non-verbal cue indicating that they want to take over. It's amazing how effective code can be in expressing an idea over a verbal description or notepad sketches. No more oral syntax descriptions!

Dedicated pair-workstations: Identical workstations with identical configurations, including editor. We use iMacs with nice big screens. Similar environments make it easy for pair switch-up. Everyone is familiar with the environment on the pair-stations, so there is no re-learning a new environment depending on who you happen to be pairing with.

3-Computer Setup: Each pair brings their laptop to dock alongside the pairing station. This enables any pair to perform research, and kick-off long running processes, without losing context on the dedicated workstation. While it takes more discipline to stay on task, we think it's worth the flexibility.

I don't claim that this is the perfect environment for all situations; but it's something that works well for us.

Today, as part of our maintainer role for 1.8.6, we published a fix as part of Ruby 1.8.6 patch-level 369 and as a part of Ruby 1.8.7 patch-level 173.

The issue was initially discovered and fixed in the Ruby 1.9.1 trunk. We backported the fix to 1.8.6 by writing a test, watching it fail, then making it pass (the same way we always do). As part of our test-driven approach, Kirk Haines then added a test in RubySpec to test for the condition. We ran the test suite on OSX, RedHat Enterprise 3, CentOS 4, 32 and 64 bit Engine Yard Solo instances, and an Engine Yard Slice to verify the fix.

Engine Yard customers have been notified about the vulnerability via email with instructions on how to upgrade. Engine Yard Solo customers can get the new, patched version of Ruby 1.8.6 simply by redeploying their environments. In the future, new Engine Yard deployments will automatically get the new version.

As a result of that great feedback (thanks!), we have another announcement to make – and we think this one might get you even more excited than the others…

As of today’s feature push, we’ve completed the first generation of features (and bug-fixes) for Engine Yard Solo! Since launching, we’ve added support for custom recipes, volume snapshots, crontab management and many other essential features for managing a business-quality rails site. We’ve also improved our user interface and added help guides to the Solo support site.

On to the shiny parts: Solo is ready for a broader audience, and to enable that, we’re lowering pricing significantly. What are the main changes, you ask?

New $25 Monthly Minimum

We know that once you try Solo, you’ll love it, so we want to make it a lot more accessible. Before today, the monthly minimum charge for Engine Yard Solo was $129; based on your feedback, we’ve lowered that minimum to $25.

New Lower Usage Pricing

Solo is a great solution for applications that need the resource of a larger sized instance, so we thought we’d lower your costs a bit. An XL instance used to be $1.42 per hour; now it’s $0.90 per hour. A standard instance used to be $0.18 per hour, now it’s $0.16 per hour. Existing customers will automatically inherit this new pricing starting today.

Engine Yard prides itself on being at the cutting edge of Ruby and Rails technologies. Our customers are headed to the cloud, and we’ll be there waiting with great products and the expertise they’ve come to rely on us for.

We’ve just begun to scratch the surface, so keep an eye out: there are even more exciting developments on the way!

*not an April Fools’ Day joke!