From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Kurth Subject: Re: Security policy ambiguities - XSA-108 process post-mortem Date: Wed, 22 Oct 2014 14:05:38 +0100 Message-ID: <85CD9DFC-0DC1-4E70-ABDB-FE127C9F09DC@gmail.com> References: <20141022003517.GA784@u109add4315675089e695.ant.amazon.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xgvbk-0001cs-M2 for xen-devel@lists.xenproject.org; Wed, 22 Oct 2014 13:05:44 +0000 Received: by mail-wi0-f174.google.com with SMTP id r20so1303100wiv.13 for ; Wed, 22 Oct 2014 06:05:42 -0700 (PDT) In-Reply-To: <20141022003517.GA784@u109add4315675089e695.ant.amazon.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Matt Wilson Cc: xen-devel@lists.xenproject.org, Ian Campbell , Ian Jackson List-Id: xen-devel@lists.xenproject.org On 22 Oct 2014, at 01:41, Matt Wilson wrote: > On Tue, Oct 21, 2014 at 07:20:28PM +0100, Lars Kurth wrote: >> = >> = >> I don=92t 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 t= hink 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 extre= mely rare circumstances) - in practice however, 99.99% of all issues get re= solved 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 p= roject and we never had the AB engaged. To make this work within the existing governance, we would need the equival= ent of maintainer(s) > committer(s) > project lead for the pre-disclosure l= ist. 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 chan= ges. > = >> 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 act= ivities. Only for process changes, new projects and committer/project lead = elections. Personally, I believe that avoiding a formal vote in this case i= s 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 candidate= s we have right now are members of the Security Team. Of course this may ev= olve 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 cre= ate more transparency - at least in the short term. Please do correct me, i= f 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 b= e on the list. Regards Lars