[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [DRAFT] Coverity Access Policy
On Tue, 2013-09-24 at 13:35 -0400, Konrad Rzeszutek Wilk wrote: > 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@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. > > 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. I don't think this wording quite so clearly excludes telling your friends/blackhats/people in the pub. I prefer my original wording. > > Otherwise: > > Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> > > > > > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |