From xen-devel-bounces@lists.xen.org Fri Oct 31 22:51:08 2014
Received: (at maildrop) by bugs.xenproject.org; 31 Oct 2014 22:51:08 +0000
Received: from lists.xen.org ([50.57.142.19])
by bugs.xenproject.org with esmtp (Exim 4.80)
(envelope-from )
id 1XkL2C-0007y4-RK
for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Fri, 31 Oct 2014 22:51:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
by lists.xen.org with esmtp (Exim 4.72)
(envelope-from )
id 1XkKsP-0001gZ-1c; Fri, 31 Oct 2014 22:41:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
by lists.xen.org with esmtp (Exim 4.72)
(envelope-from ) id 1XkKsN-0001gU-1A
for xen-devel@lists.xenproject.org; Fri, 31 Oct 2014 22:40:59 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
0E/E2-02576-AFF04545; Fri, 31 Oct 2014 22:40:58 +0000
X-Env-Sender: mswilson@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1414795255!7250935!1
X-Originating-IP: [209.85.192.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received:
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 589 invoked from network); 31 Oct 2014 22:40:57 -0000
Received: from mail-pd0-f179.google.com (HELO mail-pd0-f179.google.com)
(209.85.192.179)
by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
31 Oct 2014 22:40:57 -0000
Received: by mail-pd0-f179.google.com with SMTP id g10so8092314pdj.38
for ;
Fri, 31 Oct 2014 15:40:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=sender:date:from:to:cc:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to:user-agent;
bh=hglCIjeIFJeQfHPdDSuw3kOqg/ENIucp9SFszoXkEiU=;
b=jgAsE0tzCUagqddZbWmr7EDNeYqdW5mjL8n/GK+Sd38xzZs56xP3kP2O0NRjTSWXyI
5zImw0+VJM4MQWfdwSa7Fmb/BlHczVycaIsEmGLJRmbhN1h8yJRhJqw2Djvk9XZ2SoiB
1qM+aesx2qsMesWHa8NFM75s/5GA541W5WwHbukBFBB38zsgYowJpAqzb6Vl8XVzUSJB
uMl1R4L06Fj7huTEqlUs20lOsP9cOUeWonIROSgpTcxDq5HlUABIjCECzj041jjE3CBw
k5Xmi8eBgGdsVeNg1a+cgnJ5QzRiicbmBFjVSnEy1/PZBjRGQcD9Tu0bUsqEDuEXbd0I
Zzzw==
X-Received: by 10.68.129.103 with SMTP id nv7mr27971638pbb.56.1414795255149;
Fri, 31 Oct 2014 15:40:55 -0700 (PDT)
Received: from mswilson@gmail.com (54-240-196-185.amazon.com. [54.240.196.185])
by mx.google.com with ESMTPSA id v9sm10834643pdr.62.2014.10.31.15.40.52
for
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Fri, 31 Oct 2014 15:40:53 -0700 (PDT)
Received: by mswilson@gmail.com (sSMTP sendmail emulation);
Fri, 31 Oct 2014 15:40:51 -0700
Date: Fri, 31 Oct 2014 15:40:51 -0700
From: Matt Wilson
To: Ian Jackson
Message-ID: <20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
<21557.50031.783473.873273@chiark.greenend.org.uk>
<1413894766.23337.34.camel@citrix.com>
<21586.10214.683512.296628@chiark.greenend.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21586.10214.683512.296628@chiark.greenend.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xenproject.org, Ian Campbell
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108 process
post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
On Thu, Oct 30, 2014 at 11:58:30AM +0000, Ian Jackson wrote:
[...]
> I think that people who want to be on the predisclosure list should
> make matters easy for the security team. I think it therefore is only
> fair to say that an application might be delayed if the team member
> who happens to deal with the application can't conveniently access the
> evidence that the applicant is supposed to provide.
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@u109add4315675089e695.ant.amazon.com>
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 other activities like getting a patch
applied. I don't think that this process needs to be different.
> And that an application might be rejected entirely if insufficiently
> many members of the team are able to access, and hence verify, the
> information provided.
>
>
> Or to put it another way: if the Xen Project community decides to
> reject an explicit statement along the lines I propose above, that
> won't mean that I will put my own security and privacy at risk when
> dealing with predisclosure list applications.
>
> So those applications might be delayed anyway, unless other members of
> the team want to take up the slack. Of course if the community
> doesn't like my attitude, they're free to get rid of me.
I believe that others would be happy to take up the slack, but they
may not be members of the security team. I'd rather the security team
be able to focus on the matters of preparing fixes and managing
security embargoes, and not have to spend precious time on this aspect
of the policy.
--msw
[1] http://lists.xenproject.org/archives/html/xen-devel/2014-10/threads.html#02532
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel