Update Rails or not – security issues either way • Hacker News Board

Re: Update Rails or not – security issues either way

#31

Post by tptacek » Mon, Apr 01, 2013, 4:34 PM UTC

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.

Re: Update Rails or not – security issues either way

#32

Post by jeremymcanally » Mon, Apr 01, 2013, 4:37 PM UTC

jrochkind1 wrote: post #30

Rails _needs_ to produce security-patch-only patch releases. This won't be foolproof; there is no such thing as foolproof in software development. There can still be unintentional regressions in security-patch-only releases (and even new security vulnerabilities), as well as new security vulnerabilities in other releases. Yes, nothing is foolproof. But you can work at improving your quality. Yes, there are other thin…

Well, the release policy published by the Rails team states releases like this are supposed to only have security patches, but for some reason it wasn't followed here. I'm not sure why other than the frantic "zomg there's a security hole must fix it!" fray that may have clouded their judgement.

Re: Update Rails or not – security issues either way

#33

Post by patio11 » Mon, Apr 01, 2013, 4:51 PM UTC

zwily wrote: post #26

philwelch wrote: post #16

Earlier quoted context omitted.

If you're willing to trade off stability for features, the Rails 2.3 line still receives security patches to this day. You can upgrade to Rails 3 when Rails 4 comes out. If you're willing to make a slightly different trade-off, just apply the security patches as they come out and don't upgrade minor versions without integration testing.

I have heard, but can't find an official reference to it now, that Rails 2.3 will stop receiving security updates once Rails 4 is released. (I suspect that patches will still become available for serious issues even once official support is dropped.)

Rails Core will not support 2.3.X, in any fashion, after 4.X is released. It is not relevant to their interests. It is very relevant to my interests, so watch for a coming announcement on my blog, or (an alternative) switch to Gthub's fork of 2.3.X.

Maintenance policy: https://groups.google.com/forum/m/?fromgroups#!topic/rubyonr...

Re: Update Rails or not – security issues either way

#34

Post by dasil003 » Mon, Apr 01, 2013, 5:04 PM UTC

tptacek wrote: post #31

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.…

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.

Re: Update Rails or not – security issues either way

#35

Post by sergiotapia » Mon, Apr 01, 2013, 5:07 PM UTC

superuser2 wrote: post #15

sergiotapia wrote: post #12

I've shared my sentiment here before on why I'm not going to use Rails anymore. Imagine having your code working fine, and you update a MINOR version 3.2.x - and your ORM starts returning results that it didn't used to. Heh. Not worth the heartburn. I've switched to a saner, more tought out framework. Rails is gorgeous, but not safe to use for any serious systems where you're in a small team.

What did you switch to?

ASP.Net MVC4.

Re: Update Rails or not – security issues either way

#36

Post by tptacek » Mon, Apr 01, 2013, 5:09 PM UTC

dasil003 wrote: post #34

tptacek wrote: post #31

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.…

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.

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

Re: Update Rails or not – security issues either way

#37

Post by dasil003 » Mon, Apr 01, 2013, 5:14 PM UTC

tptacek wrote: post #36

dasil003 wrote: post #34

Earlier quoted context omitted.

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.

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

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?

Re: Update Rails or not – security issues either way

#38

Post by tptacek » Mon, Apr 01, 2013, 5:23 PM UTC

dasil003 wrote: post #37

tptacek wrote: post #36

Earlier quoted context omitted.

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

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?

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.

Re: Update Rails or not – security issues either way

#39

Post by bradleyland » Mon, Apr 01, 2013, 5:37 PM UTC

tptacek wrote: post #8

locofacetwice wrote: post #3

Earlier quoted context omitted.

Or don't use Rails.

Or Linux, or MySQL.

Or Postgres.

Re: Update Rails or not – security issues either way

#40

Post by patio11 » Mon, Apr 01, 2013, 5:45 PM UTC

tptacek wrote: post #38

dasil003 wrote: post #37

Earlier quoted context omitted.

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?

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 envir…

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.