From mboxrd@z Thu Jan 1 00:00:00 1970 From: James McKenzie Subject: Re: Security policy ambiguities - XSA-108 process post-mortem Date: Mon, 19 Jan 2015 20:36:22 +0000 Message-ID: <54BD6AC6.8030302@bromium.com> References: <21557.24142.873029.148164@mariner.uk.xensource.com> <21557.50031.783473.873273@chiark.greenend.org.uk> <21558.22370.175292.5524@chiark.greenend.org.uk> <5438088F020000780003DCDC@mail.emea.novell.com> <543BC2D6.8070701@eu.citrix.com> <817F8DE966913E4D91404CA656535C84113E5998@AMSPEX01CL01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <817F8DE966913E4D91404CA656535C84113E5998@AMSPEX01CL01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 29/10/14 13:27, James Bulpin wrote: > George Dunlap writes ("Security policy ambiguities - XSA-108 process post-mortem"): >> [snip] >> >> As far as I can tell we basically have the following options: >> >> 1. Never allow people to deploy during the embargo period. >> >> 2. Always allow people to deploy during the embargo period. >> >> 3. Have the security team attempt to evaluate the risk. >> >> 4. Have individual cloud operators evaluate the risk. >> >> This seems like a recipe for disaster. 1 and 3 seem like a recipe for disaster as organizations and individual people who have become aware of issues may have legal and other obligations to their users, it would also add a fairly strong incentive for a large operator not to share any issues that they, or a contractor, had found until they had completed a mitigation. Perhaps: 5) Have the security team discuss with the discoverer if fixes should be permitted during the embargo period before the discovery is announced to the list. J.