<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html" />
- <title>Xen.org Security Problem Response Process</title>
- <meta name="description" content="Xen.org, home of the Xen® hypervisor, the powerful open source industry standard for virtualization.">
- <meta name="keywords" content="xen 2.0, xen 3.0, hypervisor, server consolidation, open source, ian pratt, virtualization, virtualisation, xen, xensource, security, vulnerability, process">
- <link href="/css/community_main7.css" rel="stylesheet" type="text/css">
- <script type="text/javascript" src="/globals/javascript.js"></script>
+<title>Xen.org Security Problem Response Process</title>
+<meta name="description" content="Xen.org, home of the Xen® hypervisor, the powerful open source industry standard for virtualization.">
+<meta name="keywords" content="xen 2.0, xen 3.0, hypervisor, server consolidation, open source, ian pratt, virtualization, virtualisation, xen, xensource, security, vulnerability, process">
+<link href="/css/community_main7.css" rel="stylesheet" type="text/css">
+<script type="text/javascript" src="/globals/javascript.js"></script>
<script type="text/javascript" src="/globals/milonic_src.js"></script>
- <script type="text/javascript">
+<script type="text/javascript">
if(ns4)_d.write("<scr"+"ipt type=text/javascript src=/globals/mmenuns4.js><\/scr"+"ipt>");
- else _d.write("<scr"+"ipt type=text/javascript src=/globals/mmenudom.js><\/scr"+"ipt>");
-
+else _d.write("<scr"+"ipt type=text/javascript src=/globals/mmenudom.js><\/scr"+"ipt>");
</script>
<script type="text/javascript" src="/globals/menu_data_xenorg_main.js"></script>
- <meta http-equiv="Content-Type" content="text/html">
- <link rel="shortcut icon" href="/favicon.ico">
-
+<meta http-equiv="Content-Type" content="text/html">
+<link rel="shortcut icon" href="/favicon.ico">
</head>
-
<body>
<table border="0" cellpadding="0" cellspacing="0" align="center" id="xen_mainTable" >
- <tr>
- <td class="mainTableTopCell"> </td>
- <td class="mainTableTopCell"> </td>
- </tr>
- <tr>
-
<td height="10" class="corner_tl"><a name="topofpage" id="topofpage"></a><img src="/images/globals/pixel.gif" alt="" width="700" height="9" /></td>
- <td class="corner_tr"> </td>
- </tr>
+<tr>
+<td class="mainTableTopCell"> </td>
+<td class="mainTableTopCell"> </td>
+</tr>
+<tr>
+<td height="10" class="corner_tl"><a name="topofpage" id="topofpage"></a><img src="/images/globals/pixel.gif" alt="" width="700" height="9" /></td>
+<td class="corner_tr"> </td>
+</tr>
<!-- header -->
- <tr>
-
<td><table border="0" align="right" cellpadding="0" cellspacing="0" id="xen_navTopTable">
+<tr>
+<td><table border="0" align="right" cellpadding="0" cellspacing="0" id="xen_navTopTable">
<tr><td><div id="xen_navTop" > </div></td></tr></table><a href="/"><img src="/images/globals/xen_logo.gif" alt="Xen" width="149" height="67" border="0" id="xen" /></a><span class="xen_tag"> </span></td>
- <td> </td>
- </tr>
- <tr>
- <td id="xen_navMainContainer"><table width="535" border="0" align="right" cellpadding="0" cellspacing="0" id="xen_navMain">
- <tr>
- <td ><img src="/globals/anchorpix.gif" alt="" name="topnav_home" width="1" height="1" id="topnav_xenhome"><a href="/" onmouseover="popup('xenhome','topnav_xenhome')" onmouseout=popdown()>Home</a></td>
- <td id="xen_navMainOn"><img src="/globals/anchorpix.gif" alt="" name="topnav_products" width="1" height="1" id="topnav_products"><a href="/products/" onmouseover="popup('products','topnav_products')" onmouseout=popdown()>Products</a></td>
- <td ><img src="/globals/anchorpix.gif" alt="" name="topnav_support" width="1" height="1" id="topnav_support"><a href="/support/" onmouseover="popup('support','topnav_support')" onmouseout=popdown()>Support</a></td>
- <td><img src="/globals/anchorpix.gif" alt="" name="topnav_community" width="1" height="1" id="topnav_community"><a href="/community/" onmouseover="popup('community','topnav_community')" onmouseout=popdown()>Community</a></td>
- <td><img src="/globals/anchorpix.gif" alt="" name="topnav_news" width="1" height="1" id="topnav_news"><a href="http://blog.xen.org/" onmouseover="popup('news','topnav_news')" onmouseout=popdown()>Blog</a></td>
- </tr>
- </table></td>
- <td id="xen_navMainContainerRt"> </td>
- </tr>
-
+<td> </td>
+</tr>
+<tr>
+<td id="xen_navMainContainer"><table width="535" border="0" align="right" cellpadding="0" cellspacing="0" id="xen_navMain">
+<tr>
+<td ><img src="/globals/anchorpix.gif" alt="" name="topnav_home" width="1" height="1" id="topnav_xenhome"><a href="/" onmouseover="popup('xenhome','topnav_xenhome')" onmouseout=popdown()>Home</a></td>
+<td id="xen_navMainOn"><img src="/globals/anchorpix.gif" alt="" name="topnav_products" width="1" height="1" id="topnav_products"><a href="/products/" onmouseover="popup('products','topnav_products')" onmouseout=popdown()>Products</a></td>
+<td ><img src="/globals/anchorpix.gif" alt="" name="topnav_support" width="1" height="1" id="topnav_support"><a href="/support/" onmouseover="popup('support','topnav_support')" onmouseout=popdown()>Support</a></td>
+<td><img src="/globals/anchorpix.gif" alt="" name="topnav_community" width="1" height="1" id="topnav_community"><a href="/community/" onmouseover="popup('community','topnav_community')" onmouseout=popdown()>Community</a></td>
+<td><img src="/globals/anchorpix.gif" alt="" name="topnav_news" width="1" height="1" id="topnav_news"><a href="http://blog.xen.org/" onmouseover="popup('news','topnav_news')" onmouseout=popdown()>Blog</a></td>
+</tr>
+</table></td>
+<td id="xen_navMainContainerRt"> </td>
+</tr>
<!-- end header -->
<!-- end header -->
-
- <tr>
- <td id="xen_navSecond"><a href="/products/index.html" >Products</a> | <a href="/products/downloads.html">Downloads</a> | <a href="/products/xenhyp.html">Xen Hypervisor</a> |
- <a href="/products/xen_arm.html">Xen ARM</a> | <a href="/products/cloudxen.html">Xen Cloud Platform</a> | <a href="/products/projects.html" class="navSecondOnpage">Projects</a> | <a href="/community/projects.html" class="xen_last">Solution Search</a> </td>
- <td id="xen_navSecondRt"> </td>
- </tr>
- <tr>
-
- <td id="xen_content"><div class="xen_navThird"> </div>
- <!-- begin callout -->
-
- <table width="100%" cellspacing="0" cellpadding="0">
- <tr valign="top">
- <td width="200"><img src="/images/blog/XenGovernanceProposalQ2_2011.png" width="180"></td>
- <td width="1"></td>
- <td>
-
- <h1>Xen.org Security Problem Response Process</h1>
- <h2>Introduction</h2>
- <p>Computer systems have bugs. Currently recognised best practice for bugs
- with security implications is to notify significant downstream users in
- private; leave a reasonable interval for downstreams to respond and prepare
- updated software packages; then make public disclosure.</p>
- <p>We want to encourage people to report bugs they find to us. Therefore we
- will treat with respect the requests of discoverers, or other vendors, who
- report problems to us.</p>
-
- <h2>Scope of this process</h2>
- <p>This process primarily covers the <a href="http://www.xen.org/products/xenhyp.html">Xen Hypervisor Project</a>. Vulnerabilties reported against other Xen.org projects will be handled on a best effort basis by the relevant Project Lead together with the security team.</p>
-
- <h2>Specific process</h2>
- <ol type="1">
- <li><p>We request that anyone who discovers a vulnerability in xen.org
- software reports this by email to security (at) xen (dot) org.</p>
- <p>(This also covers the situation where an existing published
- changeset is retrospectively found to be a security fix)</p></li>
- <li><p>Immediately, and in parallel:</p></li>
- <ol type="a">
- <li><p>Those of us on the xen.org team who are aware of the problem
- will notify security@xen if disclosure wasn't made there
- already.</p></li>
- <li><p>If the vulnerability is not already public, security@xen will
- negotiate with discoverer regarding embargo date and disclosure
- schedule. See below for detailed discussion.</p></li>
- </ol>
- <li>Furthermore, also in parallel:</li>
- <ol type="a" start="3">
- <li><p>security@xen will check whether the discoverer, or other people
- already aware of the problem, have allocated a CVE number. If
- not, we will acquire a CVE candidate number ourselves, and
- make sure that everyone who is aware of the problem is also
- aware of the CVE number.</p></li>
- <li><p>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.</p></li>
- <p>(This may rely on the other project(s) having
- documented and responsive security contact points)</p>
- <li><p>We will prepare or check patch(es) which fix the
- vulnerability. This would ideally include all relevant
- backports. Patches will be tightly targeted on fixing the
- specific security vulnerability in the smallest, simplest and
- most reliable way. Where necessary domain specific experts
- within the community will be brought in to help with patch
- preparation.</p></li>
- <li><p>We will determine which systems/configurations/versions are
- vulnerable, and what the impact of the vulnerability is.
- Depending on the nature of the vulnerability this may involve
- sharing information about the vulnerability (in confidence, if
- the issue is embargoed) with hardware vendors and/or other
- software projects.</p></li>
- <li><p>We will write a Xen advisory including information from (b)-(f)</p></li>
- </ol>
-
- <li><p><b>Advisory pre-release:</b></p>
- <p>This occurs only if the advisory is embargoed (ie, the problem is
- not already public):</p>
- <p>As soon as our advisory is available, we will send it,
- including patches, to members of the Xen security pre-disclosure
- list. For more information about this list, see below.</p>
- <p>At this stage the advisory will be clearly marked with the embargo
- date.</p>
- </li>
-
- <li><p><b>Advisory public release:</b></p>
- <p>At the embargo date we will publish the advisory, and push
- bugfix changesets to public revision control trees.</p>
- <p>Public advisories will be posted to xen-devel,
- xen-users and xen-annnounce and will be added to the
- <a href="http://wiki.xen.org/wiki/Security_Announcements">Security Announcements wiki page</a>.</p>
- <p>Copies will also be sent to the pre-disclosure list.</p>
- </li>
-
- <li><p><b>Updates</b></p>
- <p>If new information or better patches become available, or we
- discover mistakes, we may issue an amended (revision 2 or later)
- public advisory. This will also be sent to the pre-disclosure
- list.</p>
- </li>
-
- <li><p><b>Post embargo transparency:</b></p>
- <p>During an embargo period the Xen.org security response team may
- be required to make potentially controverial decisions in private,
- since they cannot confer with the community without breaking the
- embargo. The security team will attempt to make such decisions
- following the guidance of this document and where necessary their
- own best judgement. Following the embargo period any such
- decisions will be disclosed to the community in the interests of
- transparency and to help provide guidance should a similar
- decision be required in the future.</p>
- </li>
- </ol>
-
- <h2>Embargo and disclosure schedule</h2>
- <p>If a vulnerability is not already public, we would like to notify
- significant distributors and operators of Xen so that they can prepare
- patched software in advance. This will help minimise the degree to which
- there are Xen users who are vulnerable but can't get patches.</p>
- <p>As discussed, we will negotiate with discoverers about disclosure
- schedule. Our usual starting point for that negotiation, unless there are
- reasons to diverge from this, would be:</p>
- <ol type="1">
- <li><p>One working week between notification arriving at security@xen
- and the issue of our own advisory to our predisclosure list. We
- will use this time to gather information and prepare our
- advisory, including required patches.</p></li>
- <li><p>Two working weeks between issue of our advisory to our
- predisclosure list and publication.</p></li>
- </ol>
- <p>When a discoverer reports a problem to us and requests longer delays than
- we would consider ideal, we will honour such a request if reasonable. If a
- discoverer wants an accelerated disclosure compared to what we would prefer,
- we naturally do not have the power to insist that a discoverer waits for us
- to be ready and will honour the date specified by the discoverer.</p>
- <p>Naturally, if a vulnerability is being exploited in the wild we will make
- immediately public release of the advisory and patch(es) and expect others
- to do likewise.</p>
-
- <h2>Pre-disclosure list</h2>
- <p>Xen.org operates a pre-disclosure list. This list contains the email
- addresses (ideally, role addresses) of the security response teams for
- significant Xen operators and distributors.</p>
- <p>This includes:<ul>
- <li>Public hosting providers;</li>
- <li>Large-scale organisational users of Xen;</li>
- <li>Vendors of Xen-based systems;</li>
- <li>Distributors of operating systems with Xen support.</li>
- </ul></p>
- <p>This includes both corporations and community institutions.</p>
- <p>Here "provider", "vendor", and "distributor" is meant to
- include anyone who is making a genuine service, available to the
- public, whether for a fee or gratis. For projects providing a
- service for a fee, the rule of thumb of "genuine" is that you
- are offering services which people are purchasing. For gratis
- projects, the rule of thumb for "genuine" is measured in terms
- of the amount of time committed to providing the service. For
- instance, a software project which has 2-3 active developers,
- each of whom spend 3-4 hours per week doing development, is very
- likely to be accepted; whereas a project with a single developer
- who spends a few hours a month will most likey be rejected.</p>
- <p>For organizational users, a rule of thumb is that "large-scale"
- means an installed base of 300,000 or more Xen guests. Other
- well-established organisations with a mature security response
- process will be considered on a case-by-case basis.</p>
- <p>The list of entities on the pre-disclosure list is public. (Just the list
- of projects and organisations, not the actual email addresses.)</p>
- <p>If there is an embargo, the pre-disclosure list will receive
- copies of the advisory and patches, with a clearly marked embargo
- date, as soon as they are available. The pre-disclosure list will
- also receive copies of public advisories when they are first
- issued or updated.</p>
- <p>Organizations on the pre-disclosure list are expected to
- maintain the confidentiality of the vulnerability up to the
- embargo date which security@xen have agreed with the discoverer,
- and are committing to ensuring that any members/employees of that
- organisation who come into contact with confidential information
- will do so as well.</p>
- <p>Specifically, prior to the embargo date, pre-disclosure list members
- should not make available, even to their own customers and partners:<ul>
- <li>the Xen.org advisory</li>
- <li>their own advisory</li>
- <li>the impact, scope, set of vulnerable systems or the nature
- of the vulnerability</li>
- <li>revision control commits which are a fix for the problem</li>
- <li>patched software (even in binary form) without prior consultation with security@xen and/or the discoverer.</li>
- </ul></p>
- <p>List members are allowed to make available to their users only the following:<ul>
- <li>The existance of an issue</li>
- <li>The assigned XSA and CVE numbers</li>
- <li>The planned disclosure date</li>
- </ul></p>
-
- <p>Organisations who meet the criteria should contact security@xen
- if they wish to receive pre-disclosure of advisories. Please
- include in the e-mail: <ul>
- <li>The name of your organization</li>
- <li>A brief description of why you fit the criteria, along
- with evidence to support the claim</li>
- <li>A security alias e-mail address (no personal addresses --
- see below)</li>
- <li>A link to a web page with your security policy
- statement</li>
- <li>A statement to the effect that you have read this policy
- and agree to abide by the terms for inclusion in the list,
- specifically the requirements to regarding confidentiality
- during an embargo period</li>
- </ul></p>
- <p>Evidence that will be considered may include the following: <ul>
- <li>If you are a public hosting provider, a link to a web page
- with your public rates</li>
- <li>If you are a software provider, a link to a web page where
- your software can be downloaded or purchased</li>
- <li>If you are an open-source project, a link to a mailing
- list archive and/or a version control repository
- demonstrating active development</li>
- <li>A public key signed with a key which is in the PGP "strong
- set"</li>
- </ul></p>
-
- <p>Organizations already on the list who do not have a security
- alias or have not sent a statement that they have read this policy
- and will abide by it will be asked to do so.</p>
-
- <p>Organisations should not request subscription via the mailing
- list web interface, any such subscription requests will be
- rejected and ignored.</p>
- <p>A role address (such as security@example.com) should be used
- for each organisation, rather than one or more individual's
- direct email address. This helps to ensure that changes of
- personnel do not end up effectively dropping an organisation
- from the list.</p>
-
-
- <h3>Organizations on the pre-disclosure list:</h3>
- <p>This is a list of organisations on the pre-disclosure list
- (not email addresses or internal business groups).
- <ul><li>Amazon</li>
- <li>Citrix</li>
- <li>Debian</li>
- <li>Intel</li>
- <li>Linode</li>
- <li>Novell</li>
- <li>Oracle</li>
- <li>Rackspace</li>
- <li>Redhat</li>
- <li>SuSE</li>
- <li>Ubuntu</li>
- <li>Xen.org security response team</li>
- <li>Xen 3.4 stable tree maintainer</li>
- </ul></p>
-
- <h2>Change History</h2>
- <ul>
- <li><b>v1.4 Apr 2013:</b> Predisclosure list criteria changes</li>
- <li><b>v1.3 Aug 2012:</b> Various minor updates</li>
- <li><b>v1.2 Apr 2012:</b> Added pre-disclosure list</li>
- <li><b>v1.1 Feb 2012:</b> Added link to Security Announcements wiki page</li>
- <li><b>v1.0 Dec 2011:</b> Intial document published after review</li>
- </ul>
-
- </td>
- <td width="10"></td>
- </tr>
-
- </table>
- <!-- end callout -->
-
- <td> </td>
- </tr>
- <tr>
- <td class="corner_bl"> </td>
- <td class="corner_br"> </td>
- </tr>
+<tr>
+<td id="xen_navSecond"><a href="/products/index.html" >Products</a> | <a href="/products/downloads.html">Downloads</a> | <a href="/products/xenhyp.html">Xen Hypervisor</a> |
+<a href="/products/xen_arm.html">Xen ARM</a> | <a href="/products/cloudxen.html">Xen Cloud Platform</a> | <a href="/products/projects.html" class="navSecondOnpage">Projects</a> | <a href="/community/projects.html" class="xen_last">Solution Search</a> </td>
+<td id="xen_navSecondRt"> </td>
+</tr>
+<tr>
+<td id="xen_content"><div class="xen_navThird"> </div>
+<!-- begin callout -->
+<table width="100%" cellspacing="0" cellpadding="0">
+<tr valign="top">
+<td width="200"><img src="/images/blog/XenGovernanceProposalQ2_2011.png" width="180"></td>
+<td width="1"></td>
+<td>
+<h1>Xen.org Security Problem Response Process</h1>
+<h2>Introduction</h2>
+<p>Computer systems have bugs. Currently recognised best practice for bugs
+with security implications is to notify significant downstream users in
+private; leave a reasonable interval for downstreams to respond and prepare
+updated software packages; then make public disclosure.</p>
+<p>We want to encourage people to report bugs they find to us. Therefore we
+will treat with respect the requests of discoverers, or other vendors, who
+report problems to us.</p>
+<h2>Scope of this process</h2>
+<p>This process primarily covers the <a href="http://www.xen.org/products/xenhyp.html">Xen Hypervisor Project</a>. Vulnerabilties reported against other Xen.org projects will be handled on a best effort basis by the relevant Project Lead together with the security team.</p>
+<h2>Specific process</h2>
+<ol type="1">
+<li><p>We request that anyone who discovers a vulnerability in xen.org
+software reports this by email to security (at) xen (dot) org.</p>
+<p>(This also covers the situation where an existing published
+changeset is retrospectively found to be a security fix)</p></li>
+<li><p>Immediately, and in parallel:</p></li>
+<ol type="a">
+<li><p>Those of us on the xen.org team who are aware of the problem
+will notify security@xen if disclosure wasn't made there
+already.</p></li>
+<li><p>If the vulnerability is not already public, security@xen will
+negotiate with discoverer regarding embargo date and disclosure
+schedule. See below for detailed discussion.</p></li>
+</ol>
+<li>Furthermore, also in parallel:</li>
+<ol type="a" start="3">
+<li><p>security@xen will check whether the discoverer, or other people
+already aware of the problem, have allocated a CVE number. If
+not, we will acquire a CVE candidate number ourselves, and
+make sure that everyone who is aware of the problem is also
+aware of the CVE number.</p></li>
+<li><p>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.</p></li>
+<p>(This may rely on the other project(s) having
+documented and responsive security contact points)</p>
+<li><p>We will prepare or check patch(es) which fix the
+vulnerability. This would ideally include all relevant
+backports. Patches will be tightly targeted on fixing the
+specific security vulnerability in the smallest, simplest and
+most reliable way. Where necessary domain specific experts
+within the community will be brought in to help with patch
+preparation.</p></li>
+<li><p>We will determine which systems/configurations/versions are
+vulnerable, and what the impact of the vulnerability is.
+Depending on the nature of the vulnerability this may involve
+sharing information about the vulnerability (in confidence, if
+the issue is embargoed) with hardware vendors and/or other
+software projects.</p></li>
+<li><p>We will write a Xen advisory including information from (b)-(f)</p></li>
+</ol>
+<li><p><b>Advisory pre-release:</b></p>
+<p>This occurs only if the advisory is embargoed (ie, the problem is
+not already public):</p>
+<p>As soon as our advisory is available, we will send it,
+including patches, to members of the Xen security pre-disclosure
+list. For more information about this list, see below.</p>
+<p>At this stage the advisory will be clearly marked with the embargo
+date.</p>
+</li>
+<li><p><b>Advisory public release:</b></p>
+<p>At the embargo date we will publish the advisory, and push
+bugfix changesets to public revision control trees.</p>
+<p>Public advisories will be posted to xen-devel,
+xen-users and xen-annnounce and will be added to the
+<a href="http://wiki.xen.org/wiki/Security_Announcements">Security Announcements wiki page</a>.</p>
+<p>Copies will also be sent to the pre-disclosure list.</p>
+</li>
+<li><p><b>Updates</b></p>
+<p>If new information or better patches become available, or we
+discover mistakes, we may issue an amended (revision 2 or later)
+public advisory. This will also be sent to the pre-disclosure
+list.</p>
+</li>
+<li><p><b>Post embargo transparency:</b></p>
+<p>During an embargo period the Xen.org security response team may
+be required to make potentially controverial decisions in private,
+since they cannot confer with the community without breaking the
+embargo. The security team will attempt to make such decisions
+following the guidance of this document and where necessary their
+own best judgement. Following the embargo period any such
+decisions will be disclosed to the community in the interests of
+transparency and to help provide guidance should a similar
+decision be required in the future.</p>
+</li>
+</ol>
+<h2>Embargo and disclosure schedule</h2>
+<p>If a vulnerability is not already public, we would like to notify
+significant distributors and operators of Xen so that they can prepare
+patched software in advance. This will help minimise the degree to which
+there are Xen users who are vulnerable but can't get patches.</p>
+<p>As discussed, we will negotiate with discoverers about disclosure
+schedule. Our usual starting point for that negotiation, unless there are
+reasons to diverge from this, would be:</p>
+<ol type="1">
+<li><p>One working week between notification arriving at security@xen
+and the issue of our own advisory to our predisclosure list. We
+will use this time to gather information and prepare our
+advisory, including required patches.</p></li>
+<li><p>Two working weeks between issue of our advisory to our
+predisclosure list and publication.</p></li>
+</ol>
+<p>When a discoverer reports a problem to us and requests longer delays than
+we would consider ideal, we will honour such a request if reasonable. If a
+discoverer wants an accelerated disclosure compared to what we would prefer,
+we naturally do not have the power to insist that a discoverer waits for us
+to be ready and will honour the date specified by the discoverer.</p>
+<p>Naturally, if a vulnerability is being exploited in the wild we will make
+immediately public release of the advisory and patch(es) and expect others
+to do likewise.</p>
+<h2>Pre-disclosure list</h2>
+<p>Xen.org operates a pre-disclosure list. This list contains the email
+addresses (ideally, role addresses) of the security response teams for
+significant Xen operators and distributors.</p>
+<p>This includes:<ul>
+<li>Public hosting providers;</li>
+<li>Large-scale organisational users of Xen;</li>
+<li>Vendors of Xen-based systems;</li>
+<li>Distributors of operating systems with Xen support.</li>
+</ul></p>
+<p>This includes both corporations and community institutions.</p>
+<p>Here "provider", "vendor", and "distributor" is meant to
+include anyone who is making a genuine service, available to the
+public, whether for a fee or gratis. For projects providing a
+service for a fee, the rule of thumb of "genuine" is that you
+are offering services which people are purchasing. For gratis
+projects, the rule of thumb for "genuine" is measured in terms
+of the amount of time committed to providing the service. For
+instance, a software project which has 2-3 active developers,
+each of whom spend 3-4 hours per week doing development, is very
+likely to be accepted; whereas a project with a single developer
+who spends a few hours a month will most likey be rejected.</p>
+<p>For organizational users, a rule of thumb is that "large-scale"
+means an installed base of 300,000 or more Xen guests. Other
+well-established organisations with a mature security response
+process will be considered on a case-by-case basis.</p>
+<p>The list of entities on the pre-disclosure list is public. (Just the list
+of projects and organisations, not the actual email addresses.)</p>
+<p>If there is an embargo, the pre-disclosure list will receive
+copies of the advisory and patches, with a clearly marked embargo
+date, as soon as they are available. The pre-disclosure list will
+also receive copies of public advisories when they are first
+issued or updated.</p>
+<p>Organizations on the pre-disclosure list are expected to
+maintain the confidentiality of the vulnerability up to the
+embargo date which security@xen have agreed with the discoverer,
+and are committing to ensuring that any members/employees of that
+organisation who come into contact with confidential information
+will do so as well.</p>
+<p>Specifically, prior to the embargo date, pre-disclosure list members
+should not make available, even to their own customers and partners:<ul>
+<li>the Xen.org advisory</li>
+<li>their own advisory</li>
+<li>the impact, scope, set of vulnerable systems or the nature
+of the vulnerability</li>
+<li>revision control commits which are a fix for the problem</li>
+<li>patched software (even in binary form) without prior consultation with security@xen and/or the discoverer.</li>
+</ul></p>
+<p>List members are allowed to make available to their users only the following:<ul>
+<li>The existance of an issue</li>
+<li>The assigned XSA and CVE numbers</li>
+<li>The planned disclosure date</li>
+</ul></p>
+<p>Organisations who meet the criteria should contact security@xen
+if they wish to receive pre-disclosure of advisories. Please
+include in the e-mail: <ul>
+<li>The name of your organization</li>
+<li>A brief description of why you fit the criteria, along
+with evidence to support the claim</li>
+<li>A security alias e-mail address (no personal addresses --
+see below)</li>
+<li>A link to a web page with your security policy
+statement</li>
+<li>A statement to the effect that you have read this policy
+and agree to abide by the terms for inclusion in the list,
+specifically the requirements to regarding confidentiality
+during an embargo period</li>
+</ul></p>
+<p>Evidence that will be considered may include the following: <ul>
+<li>If you are a public hosting provider, a link to a web page
+with your public rates</li>
+<li>If you are a software provider, a link to a web page where
+your software can be downloaded or purchased</li>
+<li>If you are an open-source project, a link to a mailing
+list archive and/or a version control repository
+demonstrating active development</li>
+<li>A public key signed with a key which is in the PGP "strong
+set"</li>
+</ul></p>
+<p>Organizations already on the list who do not have a security
+alias or have not sent a statement that they have read this policy
+and will abide by it will be asked to do so.</p>
+<p>Organisations should not request subscription via the mailing
+list web interface, any such subscription requests will be
+rejected and ignored.</p>
+<p>A role address (such as security@example.com) should be used
+for each organisation, rather than one or more individual's
+direct email address. This helps to ensure that changes of
+personnel do not end up effectively dropping an organisation
+from the list.</p>
+<h3>Organizations on the pre-disclosure list:</h3>
+<p>This is a list of organisations on the pre-disclosure list
+(not email addresses or internal business groups).
+<ul><li>Amazon</li>
+<li>Citrix</li>
+<li>Debian</li>
+<li>Intel</li>
+<li>Linode</li>
+<li>Novell</li>
+<li>Oracle</li>
+<li>Rackspace</li>
+<li>Redhat</li>
+<li>SuSE</li>
+<li>Ubuntu</li>
+<li>Xen.org security response team</li>
+<li>Xen 3.4 stable tree maintainer</li>
+</ul></p>
+<h2>Change History</h2>
+<ul>
+<li><b>v1.4 Apr 2013:</b> Predisclosure list criteria changes</li>
+<li><b>v1.3 Aug 2012:</b> Various minor updates</li>
+<li><b>v1.2 Apr 2012:</b> Added pre-disclosure list</li>
+<li><b>v1.1 Feb 2012:</b> Added link to Security Announcements wiki page</li>
+<li><b>v1.0 Dec 2011:</b> Intial document published after review</li>
+</ul>
+</td>
+<td width="10"></td>
+</tr>
+</table>
+<!-- end callout -->
+<td> </td>
+</tr>
+<tr>
+<td class="corner_bl"> </td>
+<td class="corner_br"> </td>
+</tr>
</table>
-
-
<table border="0" cellpadding="0" cellspacing="0" align="center" id="xen_indexTable">
- <tr><td>
-
<table class="copyright">
- <tr valign="top" align="left">
- <!-- Menu -->
- <td width="2%"> </td>
- <td width="15%">
-
<a href="http://xen.org/news/press.html">Press Releases</a><br>
-
<a href="http://blog.xen.org/">Blog</a></p>
- </td>
- <td width="1%"> </td>
-
<td width="15%"><p><b>Resources:</b><br>
-
<a href="http://wiki.xen.org">Wiki</a><br>
-
<a href="http://xenbits.xen.org/">Sources</a><br>
-
<a href="http://www.xen.org/products/downloads.html">Downloads</a><br>
-
<a href="http://www.xen.org/projects/governance.html">Governance</a><br>
-
<a href="http://www.xen.org/projects/security_vulnerability_process.html">Security Information</a></p>
- </td>
- <td width="1%"> </td>
-
<td width="15%"><p><b>Connect:</b><br>
-
<a href="http://lists.xen.org/">Mailing Lists</a><br>
-
<a href="http://xen.markmail.org">Search Mailing Lists</a><br>
-
<a href="http://www.xen.org/community/irc.html">IRC</a><br>
-
<a href="http://twitter.com/xen_com_mgr">Twitter</a><br>
-
<a href="http://www.linkedin.com/groups?home=&gid=167190">LinkedIn</a></p>
- </td>
- <td width="1%"> </td>
-
<td width="15%"><p><b>Miscellaneous:</b><br>
-
<a href="mailto://community.manager@xen.org">Contact us</a><br>
-
<a href="http://xen.org/community/trademark.html">Legal and Privacy</a><br>
-
<a href="http://xen.org/community/logos.html">Trademark and Logos</a><br>
-
<a href="http://www.cafepress.co.uk/xen_org">Merchandise</a><br>
-
<a href="http://xen.org/community/jobs.html">Jobs in the Community</a></p>
- </td>
- <td width="50%"> </td>
- </tr>
- </table>
- </td></tr>
- <tr>
- <td class="corner_vbl"> </td>
- <td class="corner_vbr"> </td>
- </tr>
+<tr><td>
+<table class="copyright">
+<tr valign="top" align="left">
+<!-- Menu -->
+<td width="2%"> </td>
+<td width="15%">
+<p><b>News:</b><br>
+<a href="http://xen.org/news/press.html">Press Releases</a><br>
+<a href="http://blog.xen.org/">Blog</a></p>
+</td>
+<td width="1%"> </td>
+<td width="15%"><p><b>Resources:</b><br>
+<a href="http://wiki.xen.org">Wiki</a><br>
+<a href="http://xenbits.xen.org/">Sources</a><br>
+<a href="http://www.xen.org/products/downloads.html">Downloads</a><br>
+<a href="http://www.xen.org/projects/governance.html">Governance</a><br>
+<a href="http://www.xen.org/projects/security_vulnerability_process.html">Security Information</a></p>
+</td>
+<td width="1%"> </td>
+<td width="15%"><p><b>Connect:</b><br>
+<a href="http://lists.xen.org/">Mailing Lists</a><br>
+<a href="http://xen.markmail.org">Search Mailing Lists</a><br>
+<a href="http://www.xen.org/community/irc.html">IRC</a><br>
+<a href="http://twitter.com/xen_com_mgr">Twitter</a><br>
+<a href="http://www.linkedin.com/groups?home=&gid=167190">LinkedIn</a></p>
+</td>
+<td width="1%"> </td>
+<td width="15%"><p><b>Miscellaneous:</b><br>
+<a href="mailto://community.manager@xen.org">Contact us</a><br>
+<a href="http://xen.org/community/trademark.html">Legal and Privacy</a><br>
+<a href="http://xen.org/community/logos.html">Trademark and Logos</a><br>
+<a href="http://www.cafepress.co.uk/xen_org">Merchandise</a><br>
+<a href="http://xen.org/community/jobs.html">Jobs in the Community</a></p>
+</td>
+<td width="50%"> </td>
+</tr>
+</table>
+</td></tr>
+<tr>
+<td class="corner_vbl"> </td>
+<td class="corner_vbr"> </td>
+</tr>
</table>
-
<!-- Copyright -->
<table cellpadding="0" align="center" width="895px">
- <tr valign="center">
- <td class="copyright">
- <script language="JavaScript">
- <!--
- document.write(" 2005-");
- today=new Date();
- year0=today.getFullYear();
- document.write(year0);
- //-->
- </script>
- <noscript>
- ©
- </noscript><br>
- Citrix Systems, Inc. All rights reserved. </p>
- </td>
-
<td align="right"><img src="/images/globals/Citrix_Logo.png" alt="Citrix" width="90"></td>
- </tr>
+<tr valign="center">
+<td class="copyright">
+<p>Copyright
+<script language="JavaScript">
+<!--
+document.write(" 2005-");
+today=new Date();
+year0=today.getFullYear();
+document.write(year0);
+//-->
+</script>
+<noscript>
+©
+</noscript><br>
+Citrix Systems, Inc. All rights reserved. </p>
+</td>
+<td align="right"><img src="/images/globals/Citrix_Logo.png" alt="Citrix" width="90"></td>
+</tr>
</table>
-
<!-- Hosting -->
<table cellpadding="0" align="center" width="915px">
- <tr><td><hr></td></tr>
+<tr><td><hr></td></tr>
</table>
<table cellpadding="0" align="center" width="895px">
- <tr valign="top">
-
<td width="70px"><img src="/images/globals/Rackspace_Logo_Small.png" alt="Rackspace"></td>
- <td class="copyright">
-
<p>Xen.org's servers are hosted with <a href="http://www.rackspace.com/">RackSpace</a>, monitoring our<br>
- servers 24x7x365 and backed by RackSpace's Fanatical Support®.</p>
- </td>
- </tr>
+<tr valign="top">
+<td width="70px"><img src="/images/globals/Rackspace_Logo_Small.png" alt="Rackspace"></td>
+<td class="copyright">
+<p>Xen.org's servers are hosted with <a href="http://www.rackspace.com/">RackSpace</a>, monitoring our<br>
+servers 24x7x365 and backed by RackSpace's Fanatical Support®.</p>
+</td>
+</tr>
</table>
-
-
<!-- Asynchronous tracking code introduced in Q1 2011 -->
<script type="text/javascript">
- var _gaq = _gaq || [];
- _gaq.push(['_setAccount', 'UA-21816382-1']);
- _gaq.push(['_setDomainName', '.xen.org']);
- _gaq.push(['_trackPageview']);
-
- (function() {
- var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
- ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
- var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
- })();
+var _gaq = _gaq || [];
+_gaq.push(['_setAccount', 'UA-21816382-1']);
+_gaq.push(['_setDomainName', '.xen.org']);
+_gaq.push(['_trackPageview']);
+(function() {
+var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
+ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
+var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
+})();
</script></body>
</html>
projects / people / larsk / security-process.git / commitdiff