[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH v2 SECURITY-POLICY 3/9] Deployment with Security Team Permission

Permitting deployment during embargo seemed to have rough consensus on
the principle.  We seemed to be converging on the idea that the
Security Team should explicitly set deployment restrictions for each
set of patches.

 * Add new section to Security Team's advisory template.
 * Add new section to any existing outstanding embargoed advisories.

Signed-off-by: Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
 security_vulnerability_process.html |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/security_vulnerability_process.html 
index 010cf76..de5e83e 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -212,6 +212,17 @@ following:</p>
   <li>The assigned XSA number</li>
   <li>The planned disclosure date</li>
+<p>List members may, if (and only if) the Security Team grants
+permission, deploy fixed versions during the embargo.  Permission for
+deployment, and any restrictions, will be stated in the embargoed
+advisory text.</p>
+<p>The Security Team will normally permit such deployment, even for
+systems where VMs are managed or used by non-members of the
+predisclosure list.  The Security Team will impose deployment
+restrictions only insofar as it is necessary to prevent the exposure
+of technicalities (for example, differences in behaviour) which
+present a significant risk of rediscovery of the vulnerability.  Such
+situations are expected to be rare.</p>
 <p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
 permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.</p>

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.