41–48 of 48 posts
Earlier quoted context omitted.
Or Linux, or MySQL.
Or Postgres.
I'm not sure I'd put Postgres alongside Linux and Rails in terms of handling security issues.
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…
Earlier quoted context omitted.
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…
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 an…
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.
So what was the issue from Rails, specifically?
Specifically that the security releases included changes to the way that ActiveRecord works (which were unrelated to the security issues). As a consequence, their search queries were scoped differently than what they had intended. So their choice was roll back the security release, or modify their app to accommodate ActiveRecord's altered behavior.
Do you know how many Rails developers I've heard pissing on Flash or Java and its security vulnerabilities? Many - until recently. Now suddeningly these faults are an accepted aspect of Rails development. Really. I guess this more of a rant about how unfairly the Rails community (ie. dhh) has been on others, but now expects critics to look away while it happens in the Rails community on a weekly basis.
I'm guessing this schadenfreude must be delicious, since everyone keeps coming back for additional helpings. Look, gloating over other people's security issues is shitty behavior, and frankly responsible developers don't do it. Am I calling DHH an irresponsible developer? Yeah. But the Rails core team has thankfully incorporated a number of smart and responsible developers over the past 4 years, and you see a whole l…
So what was the issue from Rails, specifically?
Specifically that the security releases included changes to the way that ActiveRecord works (which were unrelated to the security issues). As a consequence, their search queries were scoped differently than what they had intended. So their choice was roll back the security release, or modify their app to accommodate ActiveRecord's altered behavior.
There were ALSO unrelated changes (quite many) in the patch release that included the latest security fixes. Which is a mess.
But, the _particular_ problem here, the OP suggests it was the same problem as github reported [here](https://github.com/blog/1440-today-s-email-incident), where they suggest they isolated the introduction of the regression to [this commit](https://github.com/rails/rails/commit/f980289fd2c1b9073a94b5...), which in fact has a commit message as the fix to CVE-2013-1854.
So, yes, a security fix unintentionally introduced a regression with _other_ security implications. Yeah, this is kind of ironic, and yeah, it means it's not so simple to say what could have been done to avoid it. (In this case, I'm surprised there wasn't an automated test already that caught the particular regression. It seems like something that should have been tested. But I haven't looked at the test source to see if it was an odd edge case or what have you.)
(But it's STILL bad practice to release security patches only in releases bundled with a bunch of other changes).
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.)
Earlier quoted context omitted.
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...