[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



George Dunlap writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 
process post-mortem"):
> On Mon, Nov 10, 2014 at 5:29 PM, Ian Jackson
> > Such a system would (a) be unworkable in practice, because no-one
> > really cares about this kind of tedious makework, and (b) at serious
> > risk of favouritism (or its opposite).
> 
> "It's opposite" meaning, "We all hate company X, so let's not let them
> join the list"?

Yes.

> > I don't want to criticise another community's process, but I strongly
> > feel that our arrangements should have broad eligibility based on
> > objective criteria.
> 
> Having black-and-white rules is nice and simple and safe; but in most
> reasonably "rich" domains, it's very difficult to come up with simple,
> objective criteria that cover all situations satisfactorily.  This is
> true in morality and law; my guess is that it's true here as well.
> 
> But I'd be willing to take a look at such a list; maybe I'm wrong
> about how objective we can make things. :-)

I think the spirit behind our previous criteria is objective.  The
problem we had was just that the rules didn't specify enough about the
*form of the predisclosure list application*.

That's why my proposed change doesn't actually touch the criteria part
of the policy.  It just formalises the application process.

Ian.

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


 


Rackspace

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