Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

Hi all,
I am assuming this question is in effect resolved. The proposed (and agreed) 
text basically states that security advisories state whether people will be 
allowed to deploy. The underlying assumption is that usually this is the case, 
unless there is a very good reason not to. How the security team handles these 
does not really need to be codified and could be based on whether the 
deployment would allow reverse engineering the issue (this would be very rare) 
and thus put everyone at risk, the discoverer stating that he/she not wanting a 
deployment, or any other reasons. 
Regards
Lars

> On 19 Jan 2015, at 20:36, James McKenzie <james.mckenzie@xxxxxxxxxxx> wrote:
> 
> 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.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel