No question: update Rails.<p>The security issues attributable to Rails upgrades are small in number and relatively minor.<p>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.<p>If there was one lesson I'd hope people would take away from Rails Winter of Security Madness, it is <i>be ready to patch at all times</i>. That's a good lesson for every platform, not just Rails, but Rails teams now have specific reasons to be on top of this.<p>When Rails announces security flaws, patch ASAP. If you're a professional Rails team, dry-run this well in advance; <i>know</i> you can patch at a moments notice, don't just hope.
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.
Rails _needs_ to produce security-patch-only patch releases.<p>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.<p>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.<p>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.<p>Am I missing something?
Another option is to fork Rails and use the patch files (included with the CVE) that target <i>only</i> the vulnerabilities addressed in the CVE.<p>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.<p>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.
There is no such thing as an insurmountable security configuration. No matter what you use or how you use it, there will always be new methods to compromise your data. Hackers are creative and enjoy a challenge and will continually attack systems until the end. Whether it be Rails or another framework, you will have to upgrade and address security issues forever. Developers need be realistic and understand that any system can be compromised if one tries hard enough. I don't necessarily think that you should go from rails 2 to 3 or 3 to 4 just to address security features. Better off staying in the branch you started the project in and applying the applicable patches for said security concerns. With that said, RAILS RULES!!
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.<p>Heh.<p>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.
Give a developer a Ruby-based web framework, and they can run for a day without patching, but give them anything else - even Prolog on Punchcards - and they run for so much longer!<p>Stop today, and help recovering Ruby developers onto a better path!