Re: [Xen-devel] [DRAFT] Coverity Access Policy

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/09/13 15:14, 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@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.

To help facilitate this, would it be sensible to have a separate mailing
list @xenproject.org containing the approved coverity members?  Already,
there have been several cases where I have requested a second opinion,
or just as simple discussion about .  At the moment it is fine cc'ing
security@xen and two other email addresses, but as more members join,
this will get untenable.

~Andrew

>
> 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


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