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

[Matt Wilson <msw@xxxxxxxxx>]

On Wed, Oct 22, 2014 at 02:05:38PM +0100, Lars Kurth wrote:
> 
> On 22 Oct 2014, at 01:41, Matt Wilson <msw@xxxxxxxxx> wrote:
> 
> > On Tue, Oct 21, 2014 at 07:20:28PM +0100, Lars Kurth wrote:
> >> 
> >> 
> >> I donât have an issue with such an approach, in particular as this
> >> is a proven model elsewhere. I would like to understand though how
> >> the oss-security process works in practice. Aka how are decisions
> >> made, who can join the list, how are conflicts resolved, etc. It
> >> seems to me that such a process would be more transparent and also
> >> fair. In particular, if we have clear criteria as to what needs to
> >> be in place to be eligible.
> > 
> > Indeed, the criteria for the distros and linux-distros lists are less
> > completely spelled out compared to the current Xen pre-disclosure
> > criteria. You have to look through the discussions on oss-security to
> > see how requests are evaluated. Typically there is a bias toward not
> > adding new people to the list unless there is a clear justification
> > through debate. It's much less of a "if you can tick all these boxes"
> > process and more of a discussion.
> 
> The changes on the table are really more practical and aim at
> demonstrating a) use of Xen and b) a mature security vulnerability
> process. So I don't think there is a contradiction with having
> criteria.

I don't think a) and b) are nearly enough. The bar needs to be set a
lot higher. But this is something we can discuss in a different part
of the thread.

> > Consider this similar to "how do I get my patch applied to the
> > hypervisor?" You propose a patch, it is debated, and if it is good for
> > the project it will be applied. It may not be good for the project, in
> > which case it will not be applied. Some people may say this is unfair,
> > and that individuals or organizations that get their patches applied
> > have an advantage over others.
> > 
> > What is the conflict resolution path for "my patch isn't being applied
> > to upstream Xen"? :-)
> 
> Maintainer(s) > committer(s) > project lead (> advisory board in
> some extremely rare circumstances) - in practice however, 99.99% of
> all issues get resolved at maintainers & committers stage without a
> vote. I cannot recall an issue where the project lead had to step in
> as long as I worked with the project and we never had the AB
> engaged.

I was asking tongue-in-cheek...

Usually things get sorted out through email discussion and a general
consensus is reached. I think we get a bit caught up in defining
parliamentary procedure for situations that rarely, if ever, come up.

> To make this work within the existing governance, we would need the
> equivalent of maintainer(s) > committer(s) > project lead for the
> pre-disclosure list. We don't have to have a full hierarchy: a
> project lead makes no sense in this case, or the project lead would
> just be the Xen HV project lead. If we compare with oss-sec the
> equivalent of the committer is Alexander.

To me, I think that the existing Xen Project meritocracy structure
should work. Those who do the work (i.e., frequent contributors,
maintainers, etc) have shown a commitment to the health and well-being
of the project and the community. I don't think that this needs to be
a function or system that is apart from how the community makes other
decisions.

> So I guess what I am saying is that this is doable, without governance 
> changes.

I think so too.

> >> It seems to me that if we do this, we may need to look at the
> >> Project Governance as well, as having a stake in decision making
> >> requires maintainer status today. The existing decision making
> >> process could easily be used to discuss access related to
> >> Coverity. It is not entirely clear to me whether maintainers should
> >> have to carry the burden of making decisions on who can join the
> >> pre-disclosure list.
> > 
> > I believe that strong projects have strong owners. I worry about
> > projects that fall quickly to making decisions by committee. The "two
> > +1 with no -1" model that you proposed for Coverity in [1] seems to be
> > a reasonable balance.
> 
> I stated before that we hardly ever use the voting model for
> day-to-day activities. Only for process changes, new projects and
> committer/project lead elections. Personally, I believe that
> avoiding a formal vote in this case is preferable.

+1

> So the question then would be who would be the owner (aka maintainer
> and/or committer) of the security pre-disclosure list. The only
> natural candidates we have right now are members of the Security
> Team. Of course this may evolve over time, in particular if people
> who have already a standing in the wider FOSS security community get
> actively engaged with the process.

I think that this may only really matter in cases where someone needs
to referee in the case of lack of consensus.

> So assuming that someone from the Security Team is willing to step
> up, and the community agrees, this could be done. But in practice,
> the burden would still fall onto members of Security Team and all we
> would change is to create more transparency - at least in the short
> term. Please do correct me, if you think I am wrong.

I'm not so sure. I think first we need to have community consensus on
disclosure membership decisions. This is more than transparency, it's
also moving the decision making process into the community. The only
question to me is when there isn't a community consensus, in which
case it seems like the Last Resort mechanisms in the Project
Governance should be a way to remove the burden.

> >> Also, we would need to ensure that requests are not dropped and that
> >> the required admin works (adding entities who qualify to the
> >> pre-disclosure list as well as adding them to the website).
> > 
> > I think this is the same as getting a patch applied. Patches get
> > dropped. People proposing patches send pings. Maintainers get
> > busy. This is a part of life in working with open source projects. I
> > think it's best to avoid strict request SLAs, just as we don't have a
> > "your patch will be applied in 7 days" SLA.
> 
> That is OK. A bit of a filter on the seriousness of someone
> requesting to be on the list.

--msw

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