[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem
On Fri, Oct 10, 2014 at 3:47 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>> On 09.10.14 at 01:06, <ijackson@xxxxxxxxxxxxxxxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |