|  |  | 
  
    |  |  | 
 
  |   |  | 
  
    |  |  | 
  
    |  |  | 
  
    |   xen-devel
[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.
>    (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 
States.
>    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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
 | 
 |  | 
  
    |  |  |