Re: Security policy ambiguities - XSA-108 process post-mortem

[Lars Kurth <lars.kurth.xen@gmail.com>]

On 22 Oct 2014, at 01:41, Matt Wilson <msw@linux.com> 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.

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

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. 

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

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

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. 

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.

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

Regards
Lars