[Xen-devel] [DRAFT] Coverity Access Policy

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

I've tried to codify some of the ideas put forward in the previous
thread and round out the proposal with some practicalities.

I was undecided about requiring unanimity (i.e no objections from a
maintainer) rather than just consensus. Any thoughts on that? A (well
reasoned) objection should carry a fair bit of weight under these
circumstances I think.

8<--------------------------------

The Xen Project is registered with the "Coverity Scan" service[0]
which applies Coverity's static analyser to the Open Source
projects. The tool can and does find flaws in the source code which
can include security issues.

Triaging and proposing solutions for the flaws found by Coverity is a
useful way in which Community members can contribute to the Xen
Project. However because the service may discover security issues and
the Xen Project practices responsible disclosure as described in "Xen
Security Problem Response Process"[1] the full database of issues
cannot simply be made public.

Members of the community may request access to the Coverity database
under the condition that for any security issues discovered, they:

 * agree to follow the security response process[1].
 * undertake to report security issues discovered to the security team
   (security@xxxxxxx) within 3 days of discovery.
 * waive their right to select the disclosure time line. Discoveries
   will follow the default time lines given in the policy.
 * agree to not disclose any issue discovered other than to the
   security team, unless this has been approved by the security team.

Requests should be made to the public xen-devel@xxxxxxxxxxxxxxxxxxxx
mailing list. The request must:

 * use a subject line prefixed "[COVERITY ACCESS] <Name>".
 * signal acceptance of the above conditions.
 * include a short bio of the requester, covering who they are, what,
   if any, their previous involvement with Xen has been (with
   references to patches etc), their security background and if they
   have not been previously involved with Xen why they are interested
   specifically in the Xen project. 
 * be signed by a PGP key which is part of the strong set of the PGP
   web of trust[2].

These last two items serve to help validate the identity and
trustworthiness of the person since they will be given access to
potentially sensitive information.

Seven days will be given for responses. Following the "Consensus
Decision Making" process described in the project governance
document[3]. The request must be publicly seconded ('+1') by at least
one maintainer. Objections ('-1') may be raised but must contain a
rationale.

[0] https://scan.coverity.com/faq
[1] http://www.xenproject.org/security-policy.html
[2] In practice this will be taken to mean that there is a path from a
    member of the Xen.org security team's key to the key. Several
    members of the security team have keys in the strong set.
[3] http://www.xenproject.org/governance.html



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel