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

[Tim Deegan <tim@xxxxxxx>]

At 13:56 +0100 on 14 Oct (1381758991), Ian Campbell wrote:
> Here is the updated proposal. I've addressed the comments made on the
> draft[0] and I think we can call this an actually proposal to be voted
> on.
> 
> Please indicate your support with +1 or your disagreement with a -1. If
> you disagree please provide a reason and/or an alternative proposal.

+1.

> Please reply before 1200 UTC on Monday 21 October 2013. (~1 week from
> today).
> 
> Ian.
> 
> [0] http://lists.xen.org/archives/html/xen-devel/2013-09/msg02366.html
> 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. Currently only the Xen Project Hypervisor
> (i.e. xen.git) is covered by these scans.
> 
> 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.
>  * agree to disclose the issue only to the security team and not to
>    any other third party.
>  * waive their right to select the disclosure time line. Discoveries
>    will follow the default time lines given in the policy.
> 
> 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