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.
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 15:14 +0100 on 23 Sep (1379949292), 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.This looks sensible to me. It might be worth clarifying that the scope here is xen.git (i.e. the Xen Project Hypervisor).> 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.I think the standard rules are fine. A well-reasoned objection will presumably bring out some `-1'' votes from other maintainers. Tim.> > 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. > > 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 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@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.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@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-09-23 at 15:26 +0100, Tim Deegan wrote:> At 15:14 +0100 on 23 Sep (1379949292), 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. > > This looks sensible to me. It might be worth clarifying that the scope > here is xen.git (i.e. the Xen Project Hypervisor).I suppose technically that''s just the current scope, in theory other C subprojects might use it (although I don''t think we''ve got any...) I appended to the final paragraph: Currently only the Xen Project Hypervisor (i.e. xen.git) is covered by these scans.> > 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. > > I think the standard rules are fine. A well-reasoned objection will > presumably bring out some `-1'' votes from other maintainers.True. Ian.> > Tim. > > > > > 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. > > > > 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 23.09.13 at 16:26, Tim Deegan <tim@xen.org> wrote: > At 15:14 +0100 on 23 Sep (1379949292), Ian Campbell wrote: >> 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. > > I think the standard rules are fine. A well-reasoned objection will > presumably bring out some `-1'' votes from other maintainers.I think so too. Jan
On Mon, 2013-09-23 at 15:32 +0100, Andrew Cooper wrote:> > * 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.That''s certainly something to consider. On a related not we should do as we do for the predisclosure list and list the members and the affiliations publicly I suppose. Ian.
On Tue, Sep 24, 2013 at 2:32 AM, Andrew Cooper <andrew.cooper3@citrix.com> wrote:> 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.+1 - Matthew
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 > >
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@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.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@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 > > > >
On Wed, Sep 25, 2013 at 09:34:08AM +0100, Ian Campbell wrote:> 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@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. > > I don''t think this wording quite so clearly excludes telling your > friends/blackhats/people in the pub. > > I prefer my original wording.Perhaps it is me having an English as a secondary language but I had a rough time understanding ''not'', and ''unless'' in the sentence. It made it much easier to understand when I flipped it. Maybe this: * agree to disclose the issues discovered ONLY to the security team. Unless the security team has given approval to publicily disclose it.
On Wed, 2013-09-25 at 10:26 -0400, Konrad Rzeszutek Wilk wrote:> On Wed, Sep 25, 2013 at 09:34:08AM +0100, Ian Campbell wrote: > > 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@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. > > > > I don''t think this wording quite so clearly excludes telling your > > friends/blackhats/people in the pub. > > > > I prefer my original wording. > > Perhaps it is me having an English as a secondary language but I had > a rough time understanding ''not'', and ''unless'' in the sentence. > It made it much easier to understand when I flipped it. > > Maybe this: > * agree to disclose the issues discovered ONLY to the security team. > Unless the security team has given approval to publicily disclose it.My issue with your wording was with "publicly". How about: * agree to disclose the issues discovered ONLY to the security team and not to any other party. If so I''d move it to be the bullet after "undertake to report". We can leave out the "unless approved bit", we will deal with that on a case by case basis. Ian.
On Wed, Sep 25, 2013 at 03:56:55PM +0100, Ian Campbell wrote:> On Wed, 2013-09-25 at 10:26 -0400, Konrad Rzeszutek Wilk wrote: > > On Wed, Sep 25, 2013 at 09:34:08AM +0100, Ian Campbell wrote: > > > 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@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. > > > > > > I don''t think this wording quite so clearly excludes telling your > > > friends/blackhats/people in the pub. > > > > > > I prefer my original wording. > > > > Perhaps it is me having an English as a secondary language but I had > > a rough time understanding ''not'', and ''unless'' in the sentence. > > It made it much easier to understand when I flipped it. > > > > Maybe this: > > * agree to disclose the issues discovered ONLY to the security team. > > Unless the security team has given approval to publicily disclose it. > > My issue with your wording was with "publicly". > > How about: > * agree to disclose the issues discovered ONLY to the security team > and not to any other party. > > If so I''d move it to be the bullet after "undertake to report". > > We can leave out the "unless approved bit", we will deal with that on a > case by case basis.I like that. Thank you!> > Ian. >