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/
Home Products Support Community News


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

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Re: Security vulnerability process - last call
From: Eugene Teo <eugene@xxxxxxxxxx>
Date: Wed, 20 Jul 2011 05:39:04 +0000 (UTC)
Delivery-date: Tue, 19 Jul 2011 22:45:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
References: <19998.52380.356516.189861@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Loom/3.14 (http://gmane.org/)
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 
shared with both the pre-disclosure and oss-security lists immediately, so that 
we can avoid having duplicated CVE names assigned.

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

> 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 

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

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

Thanks, Eugene
Eugene Teo / Red Hat Security Response Team

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>