Return-Path: <commits-return-57739-archive-asf-public=cust-asf.ponee.io@cloudstack.apache.org>
X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io
Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io
Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183])
	by cust-asf2.ponee.io (Postfix) with ESMTP id 6B774200C0A
	for <archive-asf-public-internal@cust-asf2.ponee.io>; Sat, 28 Jan 2017 17:36:45 +0100 (CET)
Received: by cust-asf.ponee.io (Postfix)
	id 6A285160B33; Sat, 28 Jan 2017 16:36:45 +0000 (UTC)
Delivered-To: archive-asf-public@cust-asf.ponee.io
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by cust-asf.ponee.io (Postfix) with SMTP id 64472160B5F
	for <archive-asf-public@cust-asf.ponee.io>; Sat, 28 Jan 2017 17:36:44 +0100 (CET)
Received: (qmail 25229 invoked by uid 500); 28 Jan 2017 16:36:38 -0000
Mailing-List: contact commits-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:commits-help@cloudstack.apache.org>
List-Unsubscribe: <mailto:commits-unsubscribe@cloudstack.apache.org>
List-Post: <mailto:commits@cloudstack.apache.org>
List-Id: <commits.cloudstack.apache.org>
Reply-To: dev@cloudstack.apache.org
Delivered-To: mailing list commits@cloudstack.apache.org
Received: (qmail 24948 invoked by uid 99); 28 Jan 2017 16:36:38 -0000
Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Jan 2017 16:36:38 +0000
Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33)
	id 16B73DFC47; Sat, 28 Jan 2017 16:36:38 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: swill@apache.org
To: commits@cloudstack.apache.org
Date: Sat, 28 Jan 2017 16:36:40 -0000
Message-Id: <5ad839cb00894544995975932deeb90e@git.apache.org>
In-Reply-To: <71e9b1bb02dd47b0aade9303b62e6eda@git.apache.org>
References: <71e9b1bb02dd47b0aade9303b62e6eda@git.apache.org>
X-Mailer: ASF-Git Admin Mailer
Subject: [4/5] cloudstack-www git commit: fixed some malformed html which was
 causing the security page to render incorrectly
archived-at: Sat, 28 Jan 2017 16:36:45 -0000

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/asf-site
Commit: ff1b584f3cd721eebd33db17ae79631a0b768e18
Parents: e5c333e
Author: Will Stevens <williamstevens@gmail.com>
Authored: Fri Jan 27 16:19:11 2017 -0500
Committer: Will Stevens <williamstevens@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