Update Rails or not – security issues either way
browserbite.com
browserbite.com
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.
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.
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.
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.
Remember - Rails is Omakase - meaning literally 'leave it to someeone else' - food for thought indeed.
The core value proposition for Rails has always been it incorporates enough of all of the things you need to get a web app up and running quickly, easily, and with sufficient power that your app can continue to grow into the future.
That's what DHH's original blog post screen cast was about certainly. wycats and carllerche's contributions to Rails after the Rails/Merb merge have focused both on better code discipline and ease/simplicity of use for everyone, from beginners to advanced devs.
On top of that the Rails security team has been totally on top of these disclosures and releasing patches that address them. Prominent members of the Rails community have been extraordinarily vocal in advocating that EVERYONE needs to upgrade their apps.
So, please, tell me again how Rails leaves things to others.
P.S. if you really want á la carte, use Sinatra, or Padrino.
P.P.S. Ah, if you look at the actual meaning of omakase (http://en.wikipedia.org/wiki/Omakase ), it basically means, devs entrust the defaults to the Rails team, which is basically how things actually work w/ Rails.
All I mean to say is that the implication that the Rails community has been particularly lax over security issues is simply false.
Is there room for improvement? Yeah, probably so.
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 lot less shit like that.
Even better, security issues that have languished silently since 2006 are being identified and quickly addressed.
So, no, nobody is asking anybody to look the other way. There are developers who have been in the Ruby and Rails community for a long time, who make no aspirations to being "rockstars" and are out spending their nights and weekends patching rails, and are not slagging other people off for using Java.
Think of them when you feel the inclination to rant.
(also, incidentally, most of the ranting about Flash and Java development have not focused on security issues, they've mainly focused on how awful it is to use those platforms to do development. Which is why things like JRuby are so wonderful. You get to develop in Ruby, and access the JVM's system of libraries.)
I strongly agree with 'knowtheory that gloating about security vulnerabilities is a bad habit. But this Rails/Java comparison is even worse. Nobody personalizes Java insecurity. The Java applet plugin is a mess, responsible for a huge number of compromised desktops, but nobody I know would assume that a developer who worked in Java or on the JVM would be security-illiterate. That's not true of the Rails drama, which is really an opportunity for people to piss on DHH and his personality cult, as you can see in this subthread with 'static_typed's comment.
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 things Rails could do to improve quality, including trying to actually do some variation of semver.
But the most obvious thing with the highest benefit/cost that Rails team could do is always release security patches in security patch only releases, so developers can apply security patch only releases and minimize their exposure to new regressions when doing so. Git should not make this hard to do, just cherry pick the security-patch commits into a branch created off the last release, and release it as a patch release seperately from any other changes.
Am I missing something?
The problem with upgrading to mitigate security issues is that the Rails team does not release security patches. They bump the minor-minor and do a release. That release almost always includes commits that are unrelated to the security issue. This is especially true when a lot of time passes between CVEs.
Maintaining your own branch really isn't that difficult, because you can simply merge in from upstream. In most cases, you're really only interested in patching from Rails team issued security fixes, so you won't have conflicts. If you do have conflicts, you can safely overwrite anything in your fork, because you're not developing Rails, you're simply maintaining tighter control over the release that you use.
Remember: Ruby/Rails to pose, Python for pros.
How mature.
I'm not sure I'd put Postgres alongside Linux and Rails in terms of handling security issues.
It's easier, from my viewpoint, to stick it out at a release that you know works for you, applying patches from the files contained in the CVEs. There's still a chance that the security patch will cause a regression, but at least you're not pulling in all the interim commits.
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.
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.
Maintenance policy: https://groups.google.com/forum/m/?fromgroups#!topic/rubyonr...
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).
Stop today, and help recovering Ruby developers onto a better path!