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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Therefore I would favor only first party consumers to be eligible
to join the list, and no early deployments being permitted at all.

>> Service announcements to non-list-member users during embargo
> 
> We should add just below the list of bullet points of things which may
> be disclosed:
> 
>   Where the list member is a service provider who intends to take
>   disruptive action such as rebooting as part of deploying a fix (see
>   above): the list member's communications to its users about the
>   service disruption may mention that the disruption is to correct a
>   security issue, and relate it to the public information about the
>   issue (as listed above).

The noise such occasionally (as in the case that triggered this
discussion) may create certainly doesn't help the processing of
an issue "behind the scenes" (i.e. embargoed). Yes, we do
ourselves publish the embargo expiry, but maybe we should
instead reconsider doing so rather than allowing everyone to
widely announce issues (even if indirectly), resulting in all kinds
of speculation?

>> Predisclosure list memembership

This whole final section I completely agree with.

There's one more thing I thought of btw: When we change the
policy following whatever community input we gathered (not just
now, but also in the future), people currently on the pre-disclosure
list may (at least theoretically) end up no longer qualifying for
being on the list. Shouldn't we
- add some kind of statement to the effect of implicit agreement
  to changed terms,
- provide means for list members to be removed other than by
  them asking for it?

Jan


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