Re: [DRAFT] Coverity Access Policy

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Mon, Sep 23, 2013 at 03:14:52PM +0100, Ian Campbell wrote:
> 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@xen.org) 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.

Perhaps that sentence above could be changed to:

 * agree to disclose issues discovered to the security team. Unless the
   security team has given approval to publicily disclose it.

Otherwise:

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 
> Requests should be made to the public xen-devel@lists.xenproject.org
> 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
> 
>