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.
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@xen.org) 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@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
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@xen.org) 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@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 > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
>>> On 14.10.13 at 14:56, Ian Campbell <Ian.Campbell@citrix.com> 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@xen.org) 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@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 > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On Mon, 2013-10-14 at 13:56 +0100, 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. > > Please reply before 1200 UTC on Monday 21 October 2013. (~1 week from > today).I actually left this quite a bit longer by mistake. We had two positive votes (plus my implied +1 having made the proposal) and no objections. Lars, should this be published on the www or the wiki (I can only do the latter). Cheers, Ian.> > 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@xen.org) 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@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 > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Lars, can we get this published on www please? Or shall I put it on the wiki? Ian. On Mon, 2013-11-04 at 16:23 +0000, Ian Campbell wrote:> On Mon, 2013-10-14 at 13:56 +0100, 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. > > > > Please reply before 1200 UTC on Monday 21 October 2013. (~1 week from > > today). > > I actually left this quite a bit longer by mistake. > > We had two positive votes (plus my implied +1 having made the proposal) > and no objections. > > Lars, should this be published on the www or the wiki (I can only do the > latter). > > Cheers, > Ian. > > > > > > 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@xen.org) 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@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 > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel