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.

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

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 010cf769f0dccbe3f464ece3fd645e03827d614f..de5e83e6e5bf7b170262db559af4635e33d837f2 100644 (file)
--- 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>
 </ul>
+<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>