Minor Changes to the Rails Security Policy
Posted by michael June 16, 2009 @ 09:37 AM
After reviewing the feedback on the two recent security announcements we’ve made a few minor changes to the Ruby on Rails security policy.
The first change we’ve made is to include more information on what to do if you don’t receive a response from the security team. In general reports to the security address should receive a response within 24 hours, however the sheer volume of spam to the address can, and has, lead to messages being caught in spam filters. In the event you don’t receive a response there are now two direct-emails to the people currently looking after security reports. That page will be kept up to date as responsibilities are reassigned.
The second change is to more clearly outline the announcement policy for rails vulnerabilities. In short, we notify vendor-sec ahead of the public notification to allow time for people distributing rails to prepare packages for their distributions. Then when the time has come for public notification an email is sent to the security announcement list. Finally the announcement is posted to this blog.
The security announcement list is extremely low volume and you’re strongly suggested to subscribe to it. This is the place which receives the first public announcements of all vulnerabilities in Rails, and also tends to receive additional notifications about vulnerabilities in ruby itself. We’ve been using this list for several years but judging by confusion and misinformed comments following the announcement of CVE-2009-1904, not enough people were aware of its existence.
If you have any comments on the security policy, please send them via email to security@rubyonrails.org.
That is a good idea, that you made change in your security policy.
That’s fine.
But where is Rails 2.3.3 that had to be released “in a few days” in the post from june 3rd?
Is there a way to automatically get non-breaking security updates for rails 2.3.x on production systems?
I need to migrate a rails-1.x server to new OS, new framework, etc. and am rooting for rails 2.3.3 to beat the others.
FWIW, I hope the reasons rails wasn’t selected in the following article is incorrect or will be fixed soon:
http://nobugleftbehind.com/choosing-a-development-stack-for-installable-web-applications-part-i/
http://nobugleftbehind.com/choosing-a-development-stack-for-installable-web-applications-part-ii/
@Rich I disagree (about rails) with the articles you posted… 1) Windows server?! Are you serious? 2) Rails hard to deploy? Mongrel? Nowdays with passenger rails deployment is easy, fast and scalable! Just setup a vhost and copy your application folder in your server… :)
@Andrea: agree!
We shouldn’t have to install a new version with bunch of unrelated changes just to fix a security flaw—and we should be able to install rails security updates via cron job.
And having a well-known sunset would also be immensely helpful. For example:
“Rails 2.4 (aka 2.3.3) will receive compatible bugfixes until 12/31/2009 and security updates until 12/31/2010.”
I cannot think of anything else that would provide bigger ROI in terms of boosting RoR credibility from hobbyist to enterprise.
Might I suggest using a gmail account for the inbox if spam is a problem? I haven’t had a false positive in years.
@james
GMail isn’t perfect. I have had 2 false positives with GMail that were (nearly) extremely costly. One would have delayed my website launch by a week. The other would have cost me an opportunity to meet one of the most successful entrepreneurs in the country.
@Rich (second post)
I absolutely agree!
a little off topic, but updates to this blog have really slowed down lately and I’m going through withdrawal. Please consider aborting any of your summer vacation plans so that this blog can be updated more frequently.
the new security policy is a good thing and will improve this blog.
have you still distressed yourself about the right products filling at the price?Just try www.dobizworld.com to make your successful career