Ian Jackson [Fri, 16 Jan 2015 19:51:15 +0000 (19:51 +0000)]
Clarify and fix prior consultation text
The prior consultation clause should applies to all disclosure
exceptions. The list end appears to have been moved by mistake. So
put it back.
Also, no longer suggest that predisclosure list members should consult
with the discoverer, since the discoverer is not generally known to
predisclosure list members.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Ian Jackson [Fri, 16 Jan 2015 19:51:11 +0000 (19:51 +0000)]
Explicitly permit within-list information sharing during embargo
Permitting sharing of embargoed fixes amongst predisclosure list
seemed to have appropriate consensus.
IMPLEMENTATION TASKS:
* Send a notification to the existing predisclosure list members
informing them that they have been subscribed to the new list.
Notice should point them to the policy section on filtering
by List-Id, and offer to unsubscribe them from both lists if
they prefer.
* Create the new mailing list, and
- check that it can be emailed from outside
- that messages are held for moderation and can be approved
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
v2: Obfuscate -discuss@ list's full email address with <dot>
and <span>.
Ian Jackson [Fri, 16 Jan 2015 19:51:03 +0000 (19:51 +0000)]
Tighten, and make more objective, predisclosure list application
Applicants should be required to:
- Provide information on their public web pages which makes
it clear that and why they are eligible;
- Specifically, publicly state that and how they are using Xen
(so that the Security Team can verify eligibility);
- Provide a way for members of the public to responsibly report
security problems to the applicant, just as the Xen Project does.
The Security Team should be forbidden from trying to hunt down
eligibility information etc. and should instead be mandated to reject
incomplete requests.
Also remove the "case-by-case-basis" membership exception. This is
not consistent with the new objective membership application process.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Ian Jackson [Fri, 16 Jan 2015 19:50:56 +0000 (19:50 +0000)]
Use a public mailing list for predisclosure membership applications.
IMPLEMENTATION TASKS:
* Create the mailing list (and check that it works from outside)
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
v2: Provide whole email address for predisclosure-applications@,
but obfuscate it with <dot> and a <span>.
Reword sentence about public mailing list as suggested by
Ian Campbell.
Ian Jackson [Fri, 16 Jan 2015 19:50:49 +0000 (19:50 +0000)]
Deployment with Security Team Permission
Permitting deployment during embargo seemed to have rough consensus on
the principle. We seemed to be converging on the idea that the
Security Team should explicitly set deployment restrictions for each
set of patches.
IMPLEMENTATION TASKS:
* Add new section to Security Team's advisory template.
* Add new section to any existing outstanding embargoed advisories.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
George Dunlap [Thu, 15 Nov 2012 16:15:19 +0000 (16:15 +0000)]
Expand eligibility for the pre-disclosure list
As discussed on the xen-devel mailing list, expand eligibility of the
pre-disclosure list to include any public hosting provider, as well
as software project:
* Change "Large hosting providers" to "Public hosting providers"
* Remove "widely-deployed" from vendors and distributors
* Add rules of thumb for what constitutes "genuine"
* Add an itemized list of information to be included in the application,
to make expectations clear and (hopefully) applications more streamlined.
The first will allow hosting providers of any size to join.
The second will allow software projects and vendors of any size to join.
The third and fourth will help describe exactly what criteria will be used to
determine eligibility for 1 and 2.
Additionally, this proposal adds the following requirements:
* Applicants and current members must use an e-mail alias, not an individual's
e-mail
* Applicants and current members must submit a statement saying that they have
read, understand, and will abide by this process document.
v4:
- Make it clear that the organization is committing to respecting the
secrecy, as well as committing to the secrecy of all members who are exposed
to the information during the pre-disclosure period.
v3:
- Organizations already on the list also must conform to requirements for
a security alias and a statement saying they're read and will abide by
the policy.
v2:
- Include "genuine" software providers, and a rule of thumb for "genuine"
- Include evidence for software providers
- Allow "a key signed with a key in the PGP strong set" as evidence
- Require applicants to state they have read and understand policy
and will abide by it
- Minor suggested clarifications
- Added version message at bottom
- Made security aliases a requirement
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
George Dunlap [Thu, 15 Nov 2012 15:52:08 +0000 (15:52 +0000)]
Clean up minor inconsistency re public disclosure
Include a summary of both kinds of e-mail which may be sent to the
pre-disclosure list in the "Pre-disclosure list" section, before the
discussion of what is expected of pre-disclosure list members. Also
make it consistently clear that the public disclosure will always be
sent to the pre-disclosure list.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
projects / people / iwj / security-process.git / log