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

[Matt Wilson <msw@xxxxxxxxx>]

On Tue, Oct 21, 2014 at 07:20:28PM +0100, Lars Kurth wrote:
> >>> On 21.10.14 at 16:31, <msw@xxxxxxxxx> wrote:
> > On this point in particular, back in 2012 [1] I suggested that all
> > membership requests should be discussed in public on a community email
> > list like xen-devel, or another email list to avoid noise. The Xen
> > Project Security Team shouldn't have to evaluate petitions for
> > membership while managing an embargoed issue. I brought this up again
> > in 2013 [2] regarding the Coverity process.
>
> Matt,
>
> 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.

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"? :-)

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

> Do you expect that maintainers would decide who can join the
> pre-disclosure list after a public discussion?

I think this is up for discussion. If the Xen Project community (in
particular, those who do the work) wants to take a voting approach or
an individual maintainer / set of maintainers approach. For the
distros@ list, ultimately I think it comes down to what Alexander (aka
Solar Designer <solar@xxxxxxxxxxxx>) decides to do, after being
informed by the debate and overall consensus on the list.

> Or is there another group of community members who have earned some
> kind of credibility to make decisions? And if so, who are they and
> how is credibility earned? I am assuming that oss-security has
> developed its own group of distinguished members.

It has, largely though known individuals who are active in coordinated
security response over the years. Though at the end of the day
Alexander is the one who has to do the changes to the remailer.

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

--msw

[1] http://lists.xenproject.org/archives/html/xen-devel/2013-09/msg02366.html

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