[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, 2014-10-31 at 15:40 -0700, Matt Wilson wrote: > I think that we should reduce any burden on the security team by > making this a community decision that is discussed in public, rather > than something that is handled exclusively in a closed manner as it is > today. This way others who are active community participants can help > with the decision making process can do the investigation and weigh in > on the risk/benefit tradeoff to the security process and the > project. See Message-ID: > <20141021143053.GA22864@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> > or [1] if you are willing to visit a URL. ;-) > > There's been a bit of talk about "delay" and so on. I'd rather not set > expectations on how long the processing a petition to be added to the > predisclosure list should take. Building community consensus takes > time, just as it does for I think regardless of who is processing the applications what is more important is to have a concrete set of *objective* criteria. Anyone who demonstrates that they meet those criteria must be allowed to join. It reads to me as if you are instead are proposing that the community apply some sort of subjective standard of risk/benefit tradeoffs and building consensus about a new membership. I think to take that approach (whether in public or private) would be against the previous steer from the community that the list should be fairly widely inclusive -- there will naturally be a tendency for those already inside the system to be more conservative about allowing others to join (since it increases their risk) and so they will tend (not even deliberately) to overestimate the risk of allowing new memberships. In the light of the discussions around sharing amongst predisclosure list members and pre-embargo deployment I think the inclusive nature of the list is an important balancing factor in the inherent disparity between distro style consumers and service providers. If we do not continue take an inclusive approach to the list membership then my opinion on the matter of sharing and predeploying will be very different. > other activities like getting a patch > applied. I don't think that this process needs to be different. I don't think this analogy is useful. It is rare that someone who has had a patch accepted has any incentive to prevent another essentially unrelated patch from being applied. Also, many of the reasons for not taking a patch are subjective (coding style, taste, disagreements about design issues, etc). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |