From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Security policy ambiguities - XSA-108 process post-mortem Date: Mon, 13 Oct 2014 12:23:54 +0100 Message-ID: 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.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XddjH-0003S6-PD for xen-devel@lists.xenproject.org; Mon, 13 Oct 2014 11:23:55 +0000 Received: by mail-wg0-f48.google.com with SMTP id k14so8465388wgh.7 for ; Mon, 13 Oct 2014 04:23:54 -0700 (PDT) In-Reply-To: <54380D8F020000780003DD5E@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Ian Jackson List-Id: xen-devel@lists.xenproject.org On Fri, Oct 10, 2014 at 3:47 PM, Jan Beulich wrote: >>>> On 09.10.14 at 01:06, wrote: >>> Sharing amongst predisclosure list members >> >> I think that the answer should be `yes', in principle. There seems >> little point forbidding this. >> >> Allowing greater sharing would perhaps allow problems with patches to >> be discovered (and the revised patches developed) more easily. We >> should provide a clear channel for collaboration between predisclosure >> list members. > > 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. > >> 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. On the other hand, small distros can enlist the help of other people on the list to help produce / test fixes. XenServer has a massive testing framework that can be used to make sure there aren't any accidental regressions before they publish a patch; I assume SuSE and Oracle have something similar. But how much testing bandwidth does Debian have for security fixes? At the moment CentOS doesn't have an automated framework: all testing for the XSA-108 update had to happen by hand. Being able to bring in people on the list using the xen4centos packages would have been helpful. -George