WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: Security vulnerability process - last call

To: Eugene Teo <eugene@xxxxxxxxxx>
Subject: [Xen-devel] Re: Security vulnerability process - last call
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Thu, 1 Sep 2011 17:36:27 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 01 Sep 2011 09:37:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <loom.20110720T071054-985@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Newsgroups: chiark.mail.xen.devel
References: <19998.52380.356516.189861@xxxxxxxxxxxxxxxxxxxxxxxx> <loom.20110720T071054-985@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Eugene Teo writes ("[Xen-devel] Re: Security vulnerability process - last 
call"):
> Ian Jackson <Ian.Jackson <at> eu.citrix.com> writes:
> [...]
> > 1. We request that anyone who discovers a vulnerability in xen.org
> >    software reports this by email to security (at) xen (dot) org.
> > 
> >    (This also covers the situation where an existing published
> >    changeset is retrospectively found to be a security fix.)
> 
> For this situation, the patch is already made public. Such
> information should be shared with both the pre-disclosure and
> oss-security lists immediately, so that we can avoid having
> duplicated CVE names assigned.

"Immediately" might be OK for oss-security.  But the I don't think we
want to send half-digested information to the predisclosure list.

I will add something to the draft to say we will tell oss-security
right away in this situation.

> >    (d) If we think other software systems (for example, competing
> >        hypervisor systems) are likely to be affected by the same
> >        vulnerability, we will try to make those other projects aware
> >        of the problem and include them in the advisory preparation
> >        process.  (This may rely on the other project(s) having
> >        documented and responsive security contact points.)
> 
> There's linux-distros@xxxxxxxxxxxxxxx if you are unable to find the
> necessary security contacts.

Noted, thanks.

> > 3. Advisory public release:
> > 
> >    At the embargo date we will publish the advisory, and push
> >    bugfix changesets to public revision control trees.
> 
> Perhaps be a bit more specific. At which timezone will the advisory be 
> published? For the folks in Asia Pacific, this could mean a public pre-
> disclosure of about 12 hours or more if security (at) xen is based in the 
> States.

As Ian C said, the advisory will state the a specific time, with
timezone, for the end of the embargo.  That will probably normally be
between 1200 UTC and 1600 UTC simply because of the timezone where
most of the xen.org security team are based.

Do you need something specific written in the process document about
this ?

> >    Public advisories will be posted to xen-devel.
> > 
> >    Copies will also be sent to the pre-disclosure list, unless
> >    the advisory was already sent there previously during the embargo
> >    period and has not been updated since.
> 
> And the oss-security list.

Right.

> > Specifically, prior to the embargo date, pre-disclosure list members
> > should not make available, even to their own customers and partners:
> >  - the Xen.org advisory
> >  - their own advisory
> >  - revision control commits which are a fix for the problem
> >  - patched software (even in binary form)
> > without prior consultation with security <at> xen and/or the discoverer.
> 
> Shouldn't this be "and", instead of "and/or"? And shouldn't this
> includes prior consultation with the list members too?

I think if the discoverer tells a downstream to publish something, and
doesn't consult us, that's up to the discoverer.  It shouldn't include
prior consultation with the pre-disclosure list members because that's
not a discussion list.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Re: Security vulnerability process - last call, Ian Jackson <=