[tptacek]

No question: update Rails.

The security issues attributable to Rails upgrades are small in number and relatively minor.

The security issues attributable to not upgrading Rails, and in particular in not upgrading during upgrade cycles where the Rails community was reassuring itself that everything was fine and that normal apps wouldn't be affected by security flaws, are much larger in number and extremely significant.

If there was one lesson I'd hope people would take away from Rails Winter of Security Madness, it is be ready to patch at all times. That's a good lesson for every platform, not just Rails, but Rails teams now have specific reasons to be on top of this.

When Rails announces security flaws, patch ASAP. If you're a professional Rails team, dry-run this well in advance; know you can patch at a moments notice, don't just hope.

[dasil003]

How do you dry-run a Rails patch? I mean I know how to do `bundle update rails`. The problems with updates tend to be patch-specific.

[tptacek]

If the only mechanism you have to update Rails is to do a "bundle update", start by fixing that.

[dasil003]

Huh? No, I am familiar with Ruby development and use of git and patch files. I still don't understand your point. How do you a dry-run of a patch that doesn't exist?

[tptacek]

If you are seriously on top of Rails security, you're ready to deploy workarounds if you have to, instead of waiting for the "tested" fix to percolate into Ruby gems. So, start by making an innocuous but testable patch. Add a class to ActiveSupport or something.

Also, when you drill this stuff (I think you should do it quarterly as soon as you have customers), spend as much time drilling how you'll profile your environment as you do in ensuring that your patch deployment is flawless. I worry more about hidden stale deployments than I do about production app servers.

[patio11]

I think Thomas is coming at this from a different place from many folks here, so let me explain what is animating this comment: many of you may have "monorails" apps, where everything you company does is one single Rails application. Most Rails shops eventually outgrow this architecture choice. (It's cool, I used it for ~4 years, I'm on your side.)

After you break the one app barrier, you tend to break it by a lot. Many of them will not be customer facing. For example, churn.example.com might be a simple dashboard coded up by an intern which sits behind HTTP Basic auth and just shows a dashboard with customer LTV broken down by plan. The churn app is really easy to forget: no customer ever sees it, the intern is back in college, and your team might not care about it. But e.g. the January Rails bugs were Pre-auth so you could give up code execution on churn.example.com with them. And churn.example.com sits in your datacenter and talks directly to the main database... uh oh.

If I ask you how many instances of Rails apps you have running in your company, and you can't immediately get that number from somewhere (say, an up-to-date list on an internal wiki), you should be terrified.

[static_typed]

As you said above, "Rails Winter of Security Madness, it is be ready to patch at all times" -- sounds a lot less fun than the five minute blog or scaffolded apps that drew a lot of the Rails developers into the fold in the first place, not realizing that a short while down the road they would be spending all their time patching, monkey patching and crossing-fingers each time someone lifts the hood on the framework and discovers yet another parser-in-a-parser ready to exploit.

[tptacek]

I don't know what the heck one has to do with the other. Reliably, scalably, securely deploying production applications is never going to be part of the intro screencast for a platform.

Frankly, all your comments on this thread have shared a kind of language-war tone; I'm talking about what people should be doing to secure production Rails deployments, and you tack on a dig about a screencast from 2008. In other parts of this thread, you leave wisdom like "Rails is for posers, Python for pros". On the presumption that you are a good faith commenter writing this stuff to evangelize for what you believe to be better platforms: the tactics you're using are backfiring. Your comments are going light grey, and they're discrediting the idea of evaluating platforms based on security by giving Rails partisans an easy straw man to beat down.