-<p>This document has come in effect in December 2011 and will be
-reviewed periodically (see revision sections). The last modification
-was made in February/March 2015.</p>
+<p>This document has come in effect in December 2011 and will be reviewed periodically (see revision sections). The last modification was made in February/March 2015.</p>
<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>
+<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="index.php?option=com_content&view=article&id=82:xen-hypervisor&catid=80:developers&Itemid=484">Xen
-Hypervisor Project</a>. Vulnerabilties reported against other Xen
-Project teams will be handled on a best effort basis by the relevant
-Project Lead together with the Security Response Team.</p>
+<p>This process primarily covers the <a href="index.php?option=com_content&view=article&id=82:xen-hypervisor&catid=80:developers&Itemid=484">Xen Hypervisor Project</a>. Vulnerabilties reported against other Xen Project teams will be handled on a best effort basis by the relevant Project Lead together with the Security Response Team.</p>
<h2>Specific process</h2>
<ol type="1">
- <li>
- <p>We request that anyone who discovers a vulnerability in Xen
- Project software reports this by email to security (at) xenproject
- (dot) org. (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>
- <ol type="a">
- <li>
- <p>Those of us on the Hypervisor team who are aware of the
- problem will notify security@xenproject if disclosure wasn't
- made there already.</p>
- </li>
- <li>
- <p>If the vulnerability is not already public,
- security@xenproject will negotiate with discoverer regarding
- embargo date and disclosure schedule. See below for detailed
- discussion.</p>
- </li>
- </ol></li>
- <li>Furthermore, also in parallel:<ol type="a"
- start="3"><ol type="a" start="3">
- <li>
- <p>security@xenproject 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>
- </ol></ol>
- <p>(This may rely on the other project(s) having documented and
- responsive security contact points)</p>
- <ol type="a" start="3">
- <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>
- <li>
- <p><strong>Advisory pre-release:</strong></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><strong>Advisory public release:</strong></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.xenproject.org/wiki/Security_Announcements">Security
- Announcements wiki page</a>. Copies will also be sent to the
- pre-disclosure list.</p>
- </li>
- <li>
- <p><strong>Updates</strong></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><strong>Post embargo transparency:</strong></p>
- <p>During an embargo period the 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 Response 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>
+<li>
+<p>We request that anyone who discovers a vulnerability in Xen Project software reports this by email to security (at) xenproject (dot) org. (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>
+<ol type="a">
+<li>
+<p>Those of us on the Hypervisor team who are aware of the problem will notify security@xenproject if disclosure wasn't made there already.</p>
+</li>
+<li>
+<p>If the vulnerability is not already public, security@xenproject will negotiate with discoverer regarding embargo date and disclosure schedule. See below for detailed discussion.</p>
+</li>
+</ol></li>
+<li>Furthermore, also in parallel:<ol type="a" start="3"><ol type="a" start="3">
+<li>
+<p>security@xenproject 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>
+</ol></ol>
+<p>(This may rely on the other project(s) having documented and responsive security contact points)</p>
+<ol type="a" start="3">
+<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>
+<li>
+<p><strong>Advisory pre-release:</strong></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><strong>Advisory public release:</strong></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.xenproject.org/wiki/Security_Announcements">Security Announcements wiki page</a>. Copies will also be sent to the pre-disclosure list.</p>
+</li>
+<li>
+<p><strong>Updates</strong></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><strong>Post embargo transparency:</strong></p>
+<p>During an embargo period the 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 Response 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>
+<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@xenproject 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>
+<li>
+<p>One working week between notification arriving at security@xenproject 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>
+<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>The Xen Project 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>The Xen Project 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:</p>
<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>
+<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>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.</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>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.</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>
<h3>Handling of embargoed information</h3>
-<p>Organizations on the pre-disclosure list are expected to maintain
-the confidentiality of the vulnerability up to the embargo date which
-security@xenproject 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:</p>
+<p>Organizations on the pre-disclosure list are expected to maintain the confidentiality of the vulnerability up to the embargo date which security@xenproject 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:</p>
<ul>
- <li>the Xen Project 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)</li>
-</ul>
-without prior
-consultation with security@xenproject.
-<p>List members are allowed to make available to their users only the
-following:</p>
+<li>the Xen Project 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)</li>
+</ul> without prior consultation with security@xenproject.
+<p>List members are allowed to make available to their users only the following:</p>
<ul>
- <li>The existance of an issue</li>
- <li>The assigned XSA number</li>
- <li>The planned disclosure date</li>
+<li>The existance of an issue</li>
+<li>The assigned XSA number</li>
+<li>The planned disclosure date</li>
</ul>
-<p>List members may, if (and only if) the Security Team grants
-permission, deploy fixed versions during the embargo. Permission for
-deployment, and any restrictions, will be stated in the embargoed
-advisory text.</p>
-<p>The Security Team will normally permit such deployment, even for
-systems where VMs are managed or used by non-members of the
-predisclosure list. The Security Team will impose deployment
-restrictions only insofar as it is necessary to prevent the exposure
-of technicalities (for example, differences in behaviour) which
-present a significant risk of rediscovery of the vulnerability. Such
-situations are expected to be rare.</p>
-<p>Where the list member is a service provider who intends to take
-disruptive action such as rebooting as part of deploying a fix: the
-list member's communications to its users about the service disruption
-may mention that the disruption is to correct a security issue, and
-relate it to the public information about the issue (as listed above).
-This applies whether the deployment occurs during the embargo (with
-permission - see above) or is planned for after the end of the
-embargo.</p>
-<p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
-permitted to also make available the allocated CVE number. This is no
-longer permitted in accordance with MITRE policy.</p>
+<p>List members may, if (and only if) the Security Team grants permission, deploy fixed versions during the embargo. Permission for deployment, and any restrictions, will be stated in the embargoed advisory text.</p>
+<p>The Security Team will normally permit such deployment, even for systems where VMs are managed or used by non-members of the predisclosure list. The Security Team will impose deployment restrictions only insofar as it is necessary to prevent the exposure of technicalities (for example, differences in behaviour) which present a significant risk of rediscovery of the vulnerability. Such situations are expected to be rare.</p>
+<p>Where the list member is a service provider who intends to take disruptive action such as rebooting as part of deploying a fix: the list member's communications to its users about the service disruption may mention that the disruption is to correct a security issue, and relate it to the public information about the issue (as listed above). This applies whether the deployment occurs during the embargo (with permission - see above) or is planned for after the end of the embargo.</p>
+<p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was permitted to also make available the allocated CVE number. This is no longer permitted in accordance with MITRE policy.</p>
<h3>Information-sharing amongst predisclosure list members</h3>
-<p>Predisclosure list members are allowed to share fixes to embargoed issues,
-analysis, etc., with the security teams of other list members.
-Technical measures must be taken to prevents non-list-member
-organisations, or unauthorised staff in list-member organisations,
-from obtaining the embargoed materials.</p>
+<p>Predisclosure list members are allowed to share fixes to embargoed issues, analysis, etc., with the security teams of other list members. Technical measures must be taken to prevents non-list-member organisations, or unauthorised staff in list-member organisations, from obtaining the embargoed materials.</p>
<p>The Xen Project provides the mailing list
-<code>xen-security-issues-discuss@lists.xenproject<do<span>t></span>org</code>
-for this purpose. List members are encouraged to use it but
-may share with other list members' security teams via other
-channels.<strong>[NOTE: This list has not yet been set up; we are
- working on it. --2 March 2015]</strong></p>
-<p>The <code>-discuss</code> list's distribution is identical to that of the primary
-predisclosure list <code>xen-security-issues</code>. Recipient organisations who
-do not wish to receive all of the traffic on -discuss should use
-recipient-side email filtering based on the provided <code>List-Id</code>.</p>
-<p>The <code>-discuss</code> list is moderated by the Xen Project Security Team.
-Announcements of private availability of fixed versions, and
-technical messages about embargoed advisories, will be approved.
-Messages dealing with policy matters will be rejected with a
-reference to the Security Team contact address and/or public Xen
-mailing lists.</p>
+<code>xen-security-issues-discuss@lists.xenproject<do<span>t></span>org</code> for this purpose. List members are encouraged to use it but may share with other list members' security teams via other channels.<strong>[NOTE: This list has not yet been set up; we are working on it. --2 March 2015]</strong></p>
+<p>The <code>-discuss</code> list's distribution is identical to that of the primary predisclosure list <code>xen-security-issues</code>. Recipient organisations who do not wish to receive all of the traffic on -discuss should use recipient-side email filtering based on the provided <code>List-Id</code>.</p>
+<p>The <code>-discuss</code> list is moderated by the Xen Project Security Team. Announcements of private availability of fixed versions, and technical messages about embargoed advisories, will be approved. Messages dealing with policy matters will be rejected with a reference to the Security Team contact address and/or public Xen mailing lists.</p>
<h3>Predisclosure list membership application process</h3>
-<p>Organisations who meet the criteria should contact
-predisclosure-applications@xenproject<d<span>ot</span>>org
-(which is a public mailing list) if they wish to receive
-pre-disclosure of advisories.
+<p>Organisations who meet the criteria should contact predisclosure-applications@xenproject<d<span>ot</span>>org (which is a public mailing list) if they wish to receive pre-disclosure of advisories.
<p>You must include in the e-mail:</p>
<ul>
- <li>The name of your organization</li>
- <li>Domain name(s) which you use to provide Xen software/services</li>
- <li>A brief description of why you fit the criteria</li>
- <li>If not all of your products/services use Xen, a list of (some
- of) your products/services (or categories thereof) which do.</li>
- <li>Link(s) to current public web pages, belonging to your
- organisation, for each of following pieces of information:
- <ul>
- <li>Evidence of your status as a service/software provider:
- <ul>
- <li>If you are a public hosting provider, your public rates
- or how to get a quote</li>
- <li>If you are a software provider, how your
- software can be downloaded or purchased</li>
- <li>If you are an open-source project, a mailing list
- archive and/or version control repository, with
- active development</li>
- </ul>
- </li>
- <li>Evidence of your status as a user/distributor of Xen:
- <ul>
- <li>Statements about, or descriptions of, your eligible
- production services or released software, from which it is
- immediately evident that they use Xen.
- </ul>
- </li>
- <li>Information about your handling of security problems:
- <ul>
- <li>Your invitation to members of the public, who discover
- security problems with your products/services, to report
- them in confidence to you;
- <li>Specifically, the contact information (email addresses or
- other contact instructions) which such a member of the
- public should use.
- </ul>
- </li>
- </ul>
- <p>Blog postings, conference presentations, social media pages,
- Flash presentations, videos, sites which require registration,
- anything password-protected, etc., are not acceptable. PDFs of
- reasonable size are acceptable so long as the URL you provide is
- of a ordinary HTML page providing a link to the PDF.</p>
- <p>If the pages are long and/or PDFs are involved, your email
- should say which part of the pages and documents are relevant.</p>
- </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>
- <li>The single (non-personal) email alias you wish added to the
- predisclosure list.</li>
+<li>The name of your organization</li>
+<li>Domain name(s) which you use to provide Xen software/services</li>
+<li>A brief description of why you fit the criteria</li>
+<li>If not all of your products/services use Xen, a list of (some of) your products/services (or categories thereof) which do.</li>
+<li>Link(s) to current public web pages, belonging to your organisation, for each of following pieces of information:
+<ul>
+<li>Evidence of your status as a service/software provider:
+<ul>
+<li>If you are a public hosting provider, your public rates or how to get a quote</li>
+<li>If you are a software provider, how your software can be downloaded or purchased</li>
+<li>If you are an open-source project, a mailing list archive and/or version control repository, with active development</li>
+</ul>
+</li>
+<li>Evidence of your status as a user/distributor of Xen:
+<ul>
+<li>Statements about, or descriptions of, your eligible production services or released software, from which it is immediately evident that they use Xen.
+</ul>
+</li>
+<li>Information about your handling of security problems:
+<ul>
+<li>Your invitation to members of the public, who discover security problems with your products/services, to report them in confidence to you;
+<li>Specifically, the contact information (email addresses or other contact instructions) which such a member of the public should use.
</ul>
-<p>Your application will be determined by the Xen Project Security
-Team, and their decision posted to the list. The Security Team has
-no discretion to accept applications which do not provide all of the
-information required above.</p>
-<p>If you are dissatisfied with the Security Team's decision you may
-appeal it via the Xen Project's governance processes.</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 <a href="mailto:security@example.com">security@example.com</a>)
-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>
+</li>
+</ul>
+<p>Blog postings, conference presentations, social media pages, Flash presentations, videos, sites which require registration, anything password-protected, etc., are not acceptable. PDFs of reasonable size are acceptable so long as the URL you provide is of a ordinary HTML page providing a link to the PDF.</p>
+<p>If the pages are long and/or PDFs are involved, your email should say which part of the pages and documents are relevant.</p>
+</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>
+<li>The single (non-personal) email alias you wish added to the predisclosure list.</li>
+</ul>
+<p>Your application will be determined by the Xen Project Security Team, and their decision posted to the list. The Security Team has no discretion to accept applications which do not provide all of the information required above.</p>
+<p>If you are dissatisfied with the Security Team's decision you may appeal it via the Xen Project's governance processes.</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 <a href="mailto:security@example.com">security@example.com</a>) 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).</p>
+<p>This is a list of organisations on the pre-disclosure list (not email addresses or internal business groups).</p>
<ul>
- <li>1 & 1 Internet AG</li>
- <li>Alibaba Inc.</li>
- <li>All Simple Internet Services</li>
- <li>Amazon</li>
- <li>BitFolk Ltd</li>
- <li>CentOS</li>
- <li>Citrix</li>
- <li>Debian</li>
- <li><span style="background-color:
- transparent;">drServer.net</span></li>
- <li>eApps Hosting</li>
- <li>File Sanctuary</li>
- <li>Gandi.net</li>
- <li>Gaiacom, LC</li>
- <li>GoGrid.com</li>
- <li>Host Virtual Inc.</li>
- <li>Inception Hosting Ltd</li>
- <li>Intel</li>
- <li>Invisible Things Lab</li>
- <li>iWeb Technologies Inc.</li>
- <li>LFCHosting.com</li>
- <li>Linode</li>
- <li>LiquidWeb.com</li>
- <li>Mageia</li>
- <li>mammoth.net.au</li>
- <li>Memset</li>
- <li>Namecheap Inc</li>
- <li>NFOServers.com</li>
- <li>Novell</li>
- <li>OnApp.com / SolusVM.com</li>
- <li>OnePoundWebHosting Ltd</li>
- <li>Oracle</li>
- <li>OrionVM.com</li>
- <li>prgmr.com</li>
- <li>Rackspace</li>
- <li>RailsMachine.com</li>
- <li>Redhat</li>
- <li>SecureAX Pte Ltd </li>
- <li>SoftLayer</li>
- <li>Steadfast.net</li>
- <li>SSDNodes.com</li>
- <li>SuSE</li>
- <li>Tranquil Hosting, Inc.</li>
- <li><span style="background-color: transparent;">Ubuntu</span></li>
- <li>Xen Made Easy</li>
- <li>Xen Security Response Team</li>
- <li>Xen 3.4 stable tree maintainer</li>
- <li>Zynga</li>
- <li>ZZ Servers</li>
+<li>1 & 1 Internet AG</li>
+<li>Alibaba Inc.</li>
+<li>All Simple Internet Services</li>
+<li>Amazon</li>
+<li>BitFolk Ltd</li>
+<li>CentOS</li>
+<li>Citrix</li>
+<li>Debian</li>
+<li><span style="background-color: transparent;">drServer.net</span></li>
+<li>eApps Hosting</li>
+<li>File Sanctuary</li>
+<li>Gandi.net</li>
+<li>Gaiacom, LC</li>
+<li>GoGrid.com</li>
+<li>Host Virtual Inc.</li>
+<li>Inception Hosting Ltd</li>
+<li>Intel</li>
+<li>Invisible Things Lab</li>
+<li>iWeb Technologies Inc.</li>
+<li>LFCHosting.com</li>
+<li>Linode</li>
+<li>LiquidWeb.com</li>
+<li>Mageia</li>
+<li>mammoth.net.au</li>
+<li>Memset</li>
+<li>Namecheap Inc</li>
+<li>NFOServers.com</li>
+<li>Novell</li>
+<li>OnApp.com / SolusVM.com</li>
+<li>OnePoundWebHosting Ltd</li>
+<li>Oracle</li>
+<li>OrionVM.com</li>
+<li>prgmr.com</li>
+<li>Rackspace</li>
+<li>RailsMachine.com</li>
+<li>Redhat</li>
+<li>SecureAX Pte Ltd </li>
+<li>SoftLayer</li>
+<li>Steadfast.net</li>
+<li>SSDNodes.com</li>
+<li>SuSE</li>
+<li>Tranquil Hosting, Inc.</li>
+<li><span style="background-color: transparent;">Ubuntu</span></li>
+<li>Xen Made Easy</li>
+<li>Xen Security Response Team</li>
+<li>Xen 3.4 stable tree maintainer</li>
+<li>Zynga</li>
+<li>ZZ Servers</li>
</ul>
<h2>Change History</h2>
<div class="box-note">
- <ul>
- <li><strong>v3.0 11th February 2015 (published 2nd March 2015):</strong> New predisclosure list application
- process and information-sharing and -handling rules; and, minor clarifications.</li>
- <li><strong>v2.7 Oct 21st 2014:</strong> Added the following
- vendors to the pre-disclosure list: OnePoundWebHosting Ltd, File
- Sanctuary, iWeb Technologies Inc., Memset</li>
- <li><strong>v2.6 Oct 1st 2014: </strong>Added the following
- vendors to the pre-disclosure list: eApps Hosting, Namecheap Inc,
- Gaiacom, LC</li>
- <li><strong>v2.5 Sept 30th 2014: </strong>Added the following
- vendors to the pre-disclosure list: 1 & 1 Internet AG, Alibaba
- Inc., All Simple Internet Services, BitFolk Ltd, drServer.net,
- Inception Hosting Ltd, LiquidWeb.com, RailsMachine.com, SecureAX
- Pte Ltd, Steadfast.net, Tranquil Hosting, Inc, Zynga and ZZ
- Servers</li>
- <li><strong>v2.4 Sept 29th 2014: </strong>Added the following
- vendors to the pre-disclosure list: mammoth.net.au,
- NFOServers.com, LFCHosting.com, OrionVM.com, SoftLayer and
- SSDnodes.com</li>
- <li><strong>v2.3 Sept 26th 2014:</strong> Added the following
- vendors to the pre-disclosure list: Host Virtual Inc., Gandi.net,
- GoGrid.com, OnApp.com / SolusVM.com and prgmr.com </li>
- <li><strong>v2.2 Jun 2014:</strong> In accordance with MITRE's
- guidelines it is no longer permissible to share CVE numbers of
- embargoed issues</li>
- <li><strong>v2.1 Jun 2013:</strong> Added Xen Made Easy</li>
- <li><strong>v2.0 May 2013:</strong> Significant changes to the
- document
- <ul>
- <li>Expand eligibility of who can join the predisclosure
- list</li>
- <li>Clarify definitions of who can join the predisclosure
- list</li>
- <li>Clarify information that needs to be supplied when joining
- the predisclosure list</li>
- <li>Change e-mail alias to security@xenproject</li>
- </ul>
- </li>
- <li><a href="index.php?option=com_content&view=archive&year=2013&month=3"><strong>v1.6
- Apr 2013:</strong></a> Added Mageia to predisclosure list</li>
- <li><strong>v1.5 Nov 2012:</strong> Added Invisible Things Lab to
- pre-disclosure list</li>
- <li><strong>v1.4 Oct 2012:</strong> Various minor updates</li>
- <li><strong>v1.3 Sept 2012:</strong> Added CentOS to
- pre-disclosure list</li>
- <li><strong>v1.2 Apr 2012:</strong> Added pre-disclosure list</li>
- <li><strong>v1.1 Feb 2012:</strong> Added link to Security
- Announcements wiki page</li>
- <li><strong>v1.0 Dec 2011:</strong> Intial document published
- after review</li>
- </ul>
-</div>
+<ul>
+<li><strong>v3.0 11th February 2015 (published 2nd March 2015):</strong> New predisclosure list application process and information-sharing and -handling rules; and, minor clarifications.</li>
+<li><strong>v2.7 Oct 21st 2014:</strong> Added the following vendors to the pre-disclosure list: OnePoundWebHosting Ltd, File Sanctuary, iWeb Technologies Inc., Memset</li>
+<li><strong>v2.6 Oct 1st 2014: </strong>Added the following vendors to the pre-disclosure list: eApps Hosting, Namecheap Inc, Gaiacom, LC</li>
+<li><strong>v2.5 Sept 30th 2014: </strong>Added the following vendors to the pre-disclosure list: 1 & 1 Internet AG, Alibaba Inc., All Simple Internet Services, BitFolk Ltd, drServer.net, Inception Hosting Ltd, LiquidWeb.com, RailsMachine.com, SecureAX Pte Ltd, Steadfast.net, Tranquil Hosting, Inc, Zynga and ZZ Servers</li>
+<li><strong>v2.4 Sept 29th 2014: </strong>Added the following vendors to the pre-disclosure list: mammoth.net.au, NFOServers.com, LFCHosting.com, OrionVM.com, SoftLayer and SSDnodes.com</li>
+<li><strong>v2.3 Sept 26th 2014:</strong> Added the following vendors to the pre-disclosure list: Host Virtual Inc., Gandi.net, GoGrid.com, OnApp.com / SolusVM.com and prgmr.com </li>
+<li><strong>v2.2 Jun 2014:</strong> In accordance with MITRE's guidelines it is no longer permissible to share CVE numbers of embargoed issues</li>
+<li><strong>v2.1 Jun 2013:</strong> Added Xen Made Easy</li>
+<li><strong>v2.0 May 2013:</strong> Significant changes to the document
+<ul>
+<li>Expand eligibility of who can join the predisclosure list</li>
+<li>Clarify definitions of who can join the predisclosure list</li>
+<li>Clarify information that needs to be supplied when joining the predisclosure list</li>
+<li>Change e-mail alias to security@xenproject</li>
+</ul>
+</li>
+<li><a href="index.php?option=com_content&view=archive&year=2013&month=3"><strong>v1.6 Apr 2013:</strong></a> Added Mageia to predisclosure list</li>
+<li><strong>v1.5 Nov 2012:</strong> Added Invisible Things Lab to pre-disclosure list</li>
+<li><strong>v1.4 Oct 2012:</strong> Various minor updates</li>
+<li><strong>v1.3 Sept 2012:</strong> Added CentOS to pre-disclosure list</li>
+<li><strong>v1.2 Apr 2012:</strong> Added pre-disclosure list</li>
+<li><strong>v1.1 Feb 2012:</strong> Added link to Security Announcements wiki page</li>
+<li><strong>v1.0 Dec 2011:</strong> Intial document published after review</li>
+</ul>
+</div>
\ No newline at end of file
projects / people / larsk / security-process.git / commitdiff