You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by sw...@apache.org on 2017/01/28 16:37:08 UTC

[4/4] cloudstack-www git commit: fixed some malformed html which was causing the security page to render incorrectly

fixed some malformed html which was causing the security page to render incorrectly


Project: http://git-wip-us.apache.org/repos/asf/cloudstack-www/repo
Commit: http://git-wip-us.apache.org/repos/asf/cloudstack-www/commit/ff1b584f
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-www/tree/ff1b584f
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-www/diff/ff1b584f

Branch: refs/heads/master
Commit: ff1b584f3cd721eebd33db17ae79631a0b768e18
Parents: e5c333e
Author: Will Stevens <wi...@gmail.com>
Authored: Fri Jan 27 16:19:11 2017 -0500
Committer: Will Stevens <wi...@gmail.com>
Committed: Fri Jan 27 16:19:11 2017 -0500

----------------------------------------------------------------------
 content/security.html    | 61 ++++++++++++++++++++++---------------------
 source/security.markdown | 48 ++++++++++++++++++----------------
 2 files changed, 56 insertions(+), 53 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/cloudstack-www/blob/ff1b584f/content/security.html
----------------------------------------------------------------------
diff --git a/content/security.html b/content/security.html
index a795052..4dde34a 100644
--- a/content/security.html
+++ b/content/security.html
@@ -162,38 +162,39 @@
 <h2 id="procedure-for-responding-to-potential-security-issues">Procedure for Responding to Potential Security Issues</h2>
 
 <ul>
-  <li> Upon receiving notice of a potential security issue, a security team member will create a bug to track the investigation, this bug must be flagged as a security issue. Security flag should mean contents of ticket are not visible to non-security team members
-  <li> Security team investigates the issue to confirm/deny the presence of a vulnerability within CloudStack
-  <li> If the issue is determined not to be a vulnerability the reporter will be notified and the issue will be closed as invalid
-  <li> If issue is confirmed as a CloudStack vulnerability:
-  <ul>
-    <li> Security team notifies the Apache Security team
-    <li> Security team assigns a risk rating to the vulnerability using the Common Vulnerability Scoring System
-    <li> Security team works with reporter to get a chance to investigate and mitigate the issue in a timely manner before public announcement. This should be between 15-30 days, depending on the severity and complexity of the issue
-    <li> Security team works with Apache Security Team to reserve a CVE Identifier for future public release
-    <li> Security team works with appropriate code maintainer(s) to create patch to mitigate the issue
-    <li> Testing is conducted to verify patch mitigates issue and does not cause regression errors
-    <li> Security team creates a vulnerability announcement
-    <li> Patch is committed to trunk and other supported branches that are affected.  The commit should not refer to a particular vulnerability
-    <li> A new CloudStack release or hotfix is prepared and tested, containing the new security patch
-    <li> Distributor coordination is implemented to enable a coordinated announcement
-    <li> Security team posts vulnerability announcement to...
+  <li>Upon receiving notice of a potential security issue, a security team member will create a bug to track the investigation, this bug must be flagged as a security issue. Security flag should mean contents of ticket are not visible to non-security team members</li>
+  <li>Security team investigates the issue to confirm/deny the presence of a vulnerability within CloudStack</li>
+  <li>If the issue is determined not to be a vulnerability the reporter will be notified and the issue will be closed as invalid</li>
+  <li>If issue is confirmed as a CloudStack vulnerability:
     <ul>
-      <li> CloudStack dev list
-      <li> CloudStack users list
-      <li> The Bugtraq mailing list
-    &lt;/ul&gt;
-    <li> After announcement, CHANGES and NEWS files need to be updated to reflect the vulnerability and fix. This must happen AFTER the announcement.
-    <li> Also after announcement, modify the Jira ticket so that the issue is now publicly viewable.
-  &lt;/ul&gt;
-  <li> After the vulnerability is addressed, the CloudStack community should review development processes to see how the community can minimize the chance of similar vulnerabilities being introduced in the future.
-&lt;/ul&gt;
+      <li>Security team notifies the Apache Security team</li>
+      <li>Security team assigns a risk rating to the vulnerability using the Common Vulnerability Scoring System</li>
+      <li>Security team works with reporter to get a chance to investigate and mitigate the issue in a timely manner before public announcement. This should be between 15-30 days, depending on the severity and complexity of the issue</li>
+      <li>Security team works with Apache Security Team to reserve a CVE Identifier for future public release</li>
+      <li>Security team works with appropriate code maintainer(s) to create patch to mitigate the issue</li>
+      <li>Testing is conducted to verify patch mitigates issue and does not cause regression errors</li>
+      <li>Security team creates a vulnerability announcement</li>
+      <li>Patch is committed to trunk and other supported branches that are affected.  The commit should not refer to a particular vulnerability</li>
+      <li>A new CloudStack release or hotfix is prepared and tested, containing the new security patch</li>
+      <li>Distributor coordination is implemented to enable a coordinated announcement</li>
+      <li>Security team posts vulnerability announcement to...
+        <ul>
+          <li>CloudStack dev list</li>
+          <li>CloudStack users list</li>
+          <li>The Bugtraq mailing list</li>
+        </ul>
+      </li>
+      <li>After announcement, CHANGES and NEWS files need to be updated to reflect the vulnerability and fix. This must happen AFTER the announcement.</li>
+      <li>Also after announcement, modify the Jira ticket so that the issue is now publicly viewable.</li>
+    </ul>
+  </li>
+  <li>After the vulnerability is addressed, the CloudStack community should review development processes to see how the community can minimize the chance of similar vulnerabilities being introduced in the future.</li>
+</ul>
+
+<h2 id="for-further-information">For further information</h2>
+
+<p>Further information about Apache CloudStack's security practices can be found in the <a href="https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Security">CloudStack Security wiki page</a>.</p>
 
-## For further information
-
-Further information about Apache CloudStack's security practices can be found in the [CloudStack Security wiki page](https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Security).
-
-</li></li></li></li></li></li></ul></li></li></li></li></li></li></li></li></li></li></li></ul></li></li></li></li></ul>
 
 
             <footer>

http://git-wip-us.apache.org/repos/asf/cloudstack-www/blob/ff1b584f/source/security.markdown
----------------------------------------------------------------------
diff --git a/source/security.markdown b/source/security.markdown
index ab6523e..a8ab789 100644
--- a/source/security.markdown
+++ b/source/security.markdown
@@ -39,31 +39,33 @@ The security team asks that you **please do not create publicly-viewable JIRA ti
 ## Procedure for Responding to Potential Security Issues
 
 <ul>
-  <li> Upon receiving notice of a potential security issue, a security team member will create a bug to track the investigation, this bug must be flagged as a security issue. Security flag should mean contents of ticket are not visible to non-security team members
-  <li> Security team investigates the issue to confirm/deny the presence of a vulnerability within CloudStack
-  <li> If the issue is determined not to be a vulnerability the reporter will be notified and the issue will be closed as invalid
-  <li> If issue is confirmed as a CloudStack vulnerability:
-  <ul>
-    <li> Security team notifies the Apache Security team
-    <li> Security team assigns a risk rating to the vulnerability using the Common Vulnerability Scoring System
-    <li> Security team works with reporter to get a chance to investigate and mitigate the issue in a timely manner before public announcement. This should be between 15-30 days, depending on the severity and complexity of the issue
-    <li> Security team works with Apache Security Team to reserve a CVE Identifier for future public release
-    <li> Security team works with appropriate code maintainer(s) to create patch to mitigate the issue
-    <li> Testing is conducted to verify patch mitigates issue and does not cause regression errors
-    <li> Security team creates a vulnerability announcement
-    <li> Patch is committed to trunk and other supported branches that are affected.  The commit should not refer to a particular vulnerability
-    <li> A new CloudStack release or hotfix is prepared and tested, containing the new security patch
-    <li> Distributor coordination is implemented to enable a coordinated announcement
-    <li> Security team posts vulnerability announcement to...
+  <li>Upon receiving notice of a potential security issue, a security team member will create a bug to track the investigation, this bug must be flagged as a security issue. Security flag should mean contents of ticket are not visible to non-security team members</li>
+  <li>Security team investigates the issue to confirm/deny the presence of a vulnerability within CloudStack</li>
+  <li>If the issue is determined not to be a vulnerability the reporter will be notified and the issue will be closed as invalid</li>
+  <li>If issue is confirmed as a CloudStack vulnerability:
     <ul>
-      <li> CloudStack dev list
-      <li> CloudStack users list
-      <li> The Bugtraq mailing list
+      <li>Security team notifies the Apache Security team</li>
+      <li>Security team assigns a risk rating to the vulnerability using the Common Vulnerability Scoring System</li>
+      <li>Security team works with reporter to get a chance to investigate and mitigate the issue in a timely manner before public announcement. This should be between 15-30 days, depending on the severity and complexity of the issue</li>
+      <li>Security team works with Apache Security Team to reserve a CVE Identifier for future public release</li>
+      <li>Security team works with appropriate code maintainer(s) to create patch to mitigate the issue</li>
+      <li>Testing is conducted to verify patch mitigates issue and does not cause regression errors</li>
+      <li>Security team creates a vulnerability announcement</li>
+      <li>Patch is committed to trunk and other supported branches that are affected.  The commit should not refer to a particular vulnerability</li>
+      <li>A new CloudStack release or hotfix is prepared and tested, containing the new security patch</li>
+      <li>Distributor coordination is implemented to enable a coordinated announcement</li>
+      <li>Security team posts vulnerability announcement to...
+        <ul>
+          <li>CloudStack dev list</li>
+          <li>CloudStack users list</li>
+          <li>The Bugtraq mailing list</li>
+        </ul>
+      </li>
+      <li>After announcement, CHANGES and NEWS files need to be updated to reflect the vulnerability and fix. This must happen AFTER the announcement.</li>
+      <li>Also after announcement, modify the Jira ticket so that the issue is now publicly viewable.</li>
     </ul>
-    <li> After announcement, CHANGES and NEWS files need to be updated to reflect the vulnerability and fix. This must happen AFTER the announcement.
-    <li> Also after announcement, modify the Jira ticket so that the issue is now publicly viewable.
-  </ul>
-  <li> After the vulnerability is addressed, the CloudStack community should review development processes to see how the community can minimize the chance of similar vulnerabilities being introduced in the future.
+  </li>
+  <li>After the vulnerability is addressed, the CloudStack community should review development processes to see how the community can minimize the chance of similar vulnerabilities being introduced in the future.</li>
 </ul>
 
 ## For further information