[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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.