From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bulpin Subject: Re: Security policy ambiguities - XSA-108 process post-mortem Date: Wed, 29 Oct 2014 13:27:51 +0000 Message-ID: <817F8DE966913E4D91404CA656535C84113E5991@AMSPEX01CL01.citrite.net> References: <21557.24142.873029.148164@mariner.uk.xensource.com> <21557.50031.783473.873273@chiark.greenend.org.uk> <54380D8F020000780003DD5E@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XjTI1-0000u2-6l for xen-devel@lists.xenproject.org; Wed, 29 Oct 2014 13:27:53 +0000 In-Reply-To: <54380D8F020000780003DD5E@mail.emea.novell.com> Content-Language: en-US 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.xenproject.org" List-Id: xen-devel@lists.xenproject.org Jan Beulich writes ("Security policy ambiguities - XSA-108 process post-mortem"): > [snip] > > I can see the benefits of allowing sharing, but I can also see > downsides: Along with the set of pre-disclosure list members > growing, allowing an increased amount of interchange > (including binaries) increases the risk of a leak. And since > us monitoring what is being exchanged would not be workable > in my opinion, it is also clear that it would be purely incidental > for us (or anyone else) to notice such a leak. It's a risk but I think the benefit of having far fewer vulnerable systems in production by the time the vulnerability is publically disclosed outweighs the risk. Today we have a 100% probability that there will be large numbers of vulnerable systems the day the embargo is lifted. > > One reason for permitting this is that we want fairness between > > service providers who use their own versions of Xen, and ones who use > > a version from a software provider. Both kinds of service provider > > should be able to test the fix during the embargo. > > I'm not sure about this fairness aspect. Yes, distro consumers can > apply to become a list member on their own (which I personally > dislike, but that's what the community wanted last time round). > But they're then still at the mercy of that distro provider, i.e. by > the time fixed packages get produced and internally tested, the > embargo may be over. In particular this would seem to increase > fairness only between equal size distro providers; smaller ones > may get further disadvantage from that due to their more limited > bandwidth of producing/testing/distributing fixes. > > Therefore I would favor only first party consumers to be eligible > to join the list, and no early deployments being permitted at all. I view fairness here as providing a level playing field for all concerned. If we do allow sharing then it doesn't mandate that distros will provide fixes ahead of the embargo being lifted but allows them to do so if they wish. Each distro can chose its own policy without artificial constraint. Cheers, James -- James Bulpin Sr. Director, Technology, XenServer/Networking, Cloud & Service Provider Group Citrix Systems Inc.