Add security page

security/index.html

@@ -0,0 +1,32 @@
+---
+layout: default
+title: "Ruby on Rails: Security Policy"
+---
+    <article id="article" class="security">
+      <h2>Reporting a bug</h2>
+      <p>All security bugs in rails should be reported by email to <a href="mailto:security@rubyonrails.org">security@rubyonrails.org</a>.  This list is delivered to a subset of the <a href="http://www.rubyonrails.org/core">core team</a> who handle security issues.  Your email will be acknowledged within 24 hours, and you’ll receive a more detailed response to your email within 48 hours indicating the next steps in handling your report.</p>
+      <p>This email address receives a large amount of spam, so be sure to use a descriptive subject line to avoid having your email getting lost in the spam and your report being missed.  After the initial reply to your report the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement.  As recommended by <a href="http://www.wiretrip.net/rfp/policy.html">RFPolicy</a> these updates will be sent at <strong>least</strong> every five days, in reality this is more likely to be every 24-48 hours.</p>
+      <p>If you have not received a reply to your email within 48 hours, or have not heard from the security team for the past five days there are a few steps you can take:</p>
+      <ol>
+        <li>Contact the current security coordinator (<a href="mailto:michael@koziarski.com">Michael Koziarski</a>) directly </li>
+        <li>Contact the back-up contact (<a href="mailto:jeremy@bitsweat.net">Jeremy Kemper</a>) directly.</li>
+        <li>Email the <a href="http://groups.google.com/group/rubyonrails-core">rails core list</a> or ask in #rails-contrib</li>
+      </ol>
+      <p>Please note, the rails core list and #rails-contrib are public areas.  When escalating to that address please do not discuss your issue, simply say that you’re trying to get a hold of someone from the security team.</p>
+      <h2>Disclosure Policy</h2>
+      <p>Ruby on Rails has a 5 step disclosure policy.</p>
+      <ol>
+        <li>Security report received and is assigned a primary handler.  This person will coordinate the fix and release process.</li>
+        <li>Problem is confirmed and, a list of all affected versions is determined.  Code is audited to find any potential similar problems.</li>
+        <li>Fixes are prepared for all releases which are still under maintenance (at present 2.2.x, 2.3.x, master).  These fixes are <strong>not</strong> committed to the public repository but rather held locally pending the announcement.</li>
+        <li>A suggested embargo date for this vulnerability is chosen and <a href="http://oss-security.openwall.org/wiki/mailing-lists/vendor-sec">vendor-sec</a> is notified.  This notification will include detailed instructions to reproduce, patches for all versions still under support and a contact address for packagers who need advice back-porting patches to older versions.</li>
+        <li>On the embargo date, the <a href="http://groups.google.com/group/rubyonrails-security">rails security mailing list</a> is sent a copy of the announcement.  The changes are pushed to the public repository and new gems released to rubyforge.  At least 6 hours after the mailing list is notified, a copy of the advisory will be published on <a href="http://weblog.rubyonrails.org">Riding Rails</a></li>
+      </ol>
+      <p>Typically the embargo date will be set 72 hours from the time vendor-sec is first notified, however this may vary depending on the severity of the bug or difficulty in applying a fix.</p>
+      <p>This process can take some time, especially when coordination is required with maintainers of other projects.  Every effort will be made to handle the bug in as timely a manner as possible, however it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.</p>
+      <h2>Receiving Security Updates</h2>
+      <p>The best way to receive all the security announcements is to subscribe to the <a href="http://groups.google.com/group/rubyonrails-security">rails security mailing list</a>.  The mailing list is <strong>very</strong> low traffic, and it receives the public notifications the moment the embargo is lifted.   If you produce packages of Ruby on Rails and require prior notification of vulnerabilities, you should be subscribed to vendor-sec.</p>
+      <p>No one outside the core team, the initial reporter or vendor-sec will be notified prior to the lifting of the embargo.  We regret that we cannot make exceptions to this policy for high traffic or important sites, as any disclosure beyond the minimum required to coordinate a fix could cause an early leak of the vulnerability.</p>
+      <h2>Comments on this Policy</h2>
+      <p>If you have any suggestions to improve this policy, please send an email to <a href="mailto:security@rubyonrails.org">security@rubyonrails.org</a>.</p>
+    </article>

styles.css

@@ -128,7 +128,7 @@ div.section img.biopic {
 	display: block;
 	float: right;
 }
-#article p a {
+#article p a, #article ol a {
 	color: #369;
 }
 #article p a:hover {
@@ -338,3 +338,26 @@ div.section img.biopic {
 	font-size: 14px;
 	color: #a69e8a;
 }
+/* Security Policy */
+#article.security {
+	margin: 50px auto 30px;
+	width: 700px;
+}
+#article.security h2 {
+	font-weight: bold;
+	text-transform: uppercase;
+	font-size: 20px;
+	font-family: Arial, Helvetica, sans-serif;
+	text-align: center;
+	margin: 40px 0px 15px 0px;
+}
+#article.security p, 
+#article.security ol {
+	font-family: Georgia;
+	font-size: 18px;
+	line-height: 140%;
+	margin: 0px 0px 25px 0px;
+}
+#article.security ol li {
+	margin: 0px 0px 10px 0px;
+}