Xen users - Dec 2012 - Security disclosure process discussion update

After concluding our poll [1] about changes to the security
discussion, we determined that "Pre-disclosure to software vendors and
a wide set of users" was probably the best fit for the community.  A
set of concrete changes to the policy have now been discussed on
xen-devel [2] [3], and we seem to have converged on something everyone
finds acceptable.

We are now presenting these changes for public review.  The purpose of
this review process is to allow feedback on the text which will be
voted on, in accordance to the Xen.org governance procedure [3].  Our
plan is to leave this up for review until the third week in January.
Any substantial updates will be mentioned on the blog and will extend
the review time.

All feedback and discussion should happen in public on the xen-devel
mailing list.  If you have any suggestions for how to improve the
proposal, please e-mail the list, and cc George Dunlap (george dot
dunlap at citrix.com).

= Summary of the updates 
As discussed on the xen-devel mailing list, expand eligibility of the
pre-disclosure list to include any public hosting provider, as well
as software project:
* Change "Large hosting providers" to "Public hosting
providers"
* Remove "widely-deployed" from vendors and distributors
* Add rules of thumb for what constitutes "genuine"
* Add an itemized list of information to be included in the application,
to make expectations clear and (hopefully) applications more streamlined.

The first will allow hosting providers of any size to join.

The second will allow software projects and vendors of any size to join.

The third and fourth will help describe exactly what criteria will be used
to
determine eligibility for 1 and 2.

Additionally, this proposal adds the following requirements:
* Applicants and current members must use an e-mail alias, not an
individual''s
e-mail
* Applicants and current members must submit a statement saying that they
have
read, understand, and will abide by this process document.

The new policy in its entirety can be found here:

http://wiki.xen.org/wiki/Security_vulnerability_process_draft

For comparison, the current policy can be found here:

http://www.xen.org/projects/security_vulnerability_process.html


[1]
http://blog.xen.org/index.php/2012/08/23/disclosure-process-poll-results/

[2] http://marc.info/?l=xen-devel&m=135300020310446

[3] http://marc.info/?l=xen-devel&m=135455914107182

[4] http://www.xen.org/projects/governance.html


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

After concluding our poll [1] about changes to the security
discussion, we determined that "Pre-disclosure to software vendors and
a wide set of users" was probably the best fit for the community.  A
set of concrete changes to the policy have now been discussed on
xen-devel [2] [3], and we seem to have converged on something everyone
finds acceptable.

We are now presenting these changes for public review.  The purpose of
this review process is to allow feedback on the text which will be
voted on, in accordance to the Xen.org governance procedure [3].  Our
plan is to leave this up for review until the third week in January.
Any substantial updates will be mentioned on the blog and will extend
the review time.

All feedback and discussion should happen in public on the xen-devel
mailing list.  If you have any suggestions for how to improve the
proposal, please e-mail the list, and cc George Dunlap (george dot
dunlap at citrix.com).

= Summary of the updates 
As discussed on the xen-devel mailing list, expand eligibility of the
pre-disclosure list to include any public hosting provider, as well
as software project:
* Change "Large hosting providers" to "Public hosting
providers"
* Remove "widely-deployed" from vendors and distributors
* Add rules of thumb for what constitutes "genuine"
* Add an itemized list of information to be included in the application,
to make expectations clear and (hopefully) applications more streamlined.

The first will allow hosting providers of any size to join.

The second will allow software projects and vendors of any size to join.

The third and fourth will help describe exactly what criteria will be used
to
determine eligibility for 1 and 2.

Additionally, this proposal adds the following requirements:
* Applicants and current members must use an e-mail alias, not an
individual''s
e-mail
* Applicants and current members must submit a statement saying that they
have
read, understand, and will abide by this process document.

The new policy in its entirety can be found here:

http://wiki.xen.org/wiki/Security_vulnerability_process_draft

For comparison, the current policy can be found here:

http://www.xen.org/projects/security_vulnerability_process.html


[1]
http://blog.xen.org/index.php/2012/08/23/disclosure-process-poll-results/

[2] http://marc.info/?l=xen-devel&m=135300020310446

[3] http://marc.info/?l=xen-devel&m=135455914107182

[4] http://www.xen.org/projects/governance.html


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

On Mon, Dec 17, 2012 at 12:58:13PM +0000, George Dunlap
wrote:
> After concluding our poll [1] about changes to the security
> discussion, we determined that "Pre-disclosure to software vendors and
> a wide set of users" was probably the best fit for the community.  A
> set of concrete changes to the policy have now been discussed on
> xen-devel [2] [3], and we seem to have converged on something everyone
> finds acceptable.
> 
> We are now presenting these changes for public review.  The purpose of
> this review process is to allow feedback on the text which will be
> voted on, in accordance to the Xen.org governance procedure [3].  Our
> plan is to leave this up for review until the third week in January.
> Any substantial updates will be mentioned on the blog and will extend
> the review time.
> 
> All feedback and discussion should happen in public on the xen-devel
> mailing list.  If you have any suggestions for how to improve the
> proposal, please e-mail the list, and cc George Dunlap (george dot
> dunlap at citrix.com).
> 
> = Summary of the updates > 
> As discussed on the xen-devel mailing list, expand eligibility of the
> pre-disclosure list to include any public hosting provider, as well
> as software project:
> * Change "Large hosting providers" to "Public hosting
providers"
> * Remove "widely-deployed" from vendors and distributors
> * Add rules of thumb for what constitutes "genuine"
> * Add an itemized list of information to be included in the application,
> to make expectations clear and (hopefully) applications more streamlined.
> 
> The first will allow hosting providers of any size to join.
> 
> The second will allow software projects and vendors of any size to join.
> 
> The third and fourth will help describe exactly what criteria will be used
> to
> determine eligibility for 1 and 2.
> 
> Additionally, this proposal adds the following requirements:
> * Applicants and current members must use an e-mail alias, not an
> individual''s
> e-mail
So if we use an mailing list internally..
> * Applicants and current members must submit a statement saying that they
> have
> read, understand, and will abide by this process document.
Are the folks on the internal mailing list bound by this as well? Meaning
that if a new person would like to join the internal mailing list they
need to have read, understood, etc the process document?

I would presume so, but you are not stating it here nor:

http://wiki.xen.org/wiki/Security_vulnerability_process_draft

So what is driving the ''alias'' requirement?

On Mon, Dec 17, 2012 at 12:58:13PM +0000, George Dunlap
wrote:
> After concluding our poll [1] about changes to the security
> discussion, we determined that "Pre-disclosure to software vendors and
> a wide set of users" was probably the best fit for the community.  A
> set of concrete changes to the policy have now been discussed on
> xen-devel [2] [3], and we seem to have converged on something everyone
> finds acceptable.
> 
> We are now presenting these changes for public review.  The purpose of
> this review process is to allow feedback on the text which will be
> voted on, in accordance to the Xen.org governance procedure [3].  Our
> plan is to leave this up for review until the third week in January.
> Any substantial updates will be mentioned on the blog and will extend
> the review time.
> 
> All feedback and discussion should happen in public on the xen-devel
> mailing list.  If you have any suggestions for how to improve the
> proposal, please e-mail the list, and cc George Dunlap (george dot
> dunlap at citrix.com).
> 
> = Summary of the updates > 
> As discussed on the xen-devel mailing list, expand eligibility of the
> pre-disclosure list to include any public hosting provider, as well
> as software project:
> * Change "Large hosting providers" to "Public hosting
providers"
> * Remove "widely-deployed" from vendors and distributors
> * Add rules of thumb for what constitutes "genuine"
> * Add an itemized list of information to be included in the application,
> to make expectations clear and (hopefully) applications more streamlined.
> 
> The first will allow hosting providers of any size to join.
> 
> The second will allow software projects and vendors of any size to join.
> 
> The third and fourth will help describe exactly what criteria will be used
> to
> determine eligibility for 1 and 2.
> 
> Additionally, this proposal adds the following requirements:
> * Applicants and current members must use an e-mail alias, not an
> individual''s
> e-mail
So if we use an mailing list internally..
> * Applicants and current members must submit a statement saying that they
> have
> read, understand, and will abide by this process document.
Are the folks on the internal mailing list bound by this as well? Meaning
that if a new person would like to join the internal mailing list they
need to have read, understood, etc the process document?

I would presume so, but you are not stating it here nor:

http://wiki.xen.org/wiki/Security_vulnerability_process_draft

So what is driving the ''alias'' requirement?

Dropping -announce.

On Mon, 2013-01-07 at 16:37 +0000, Konrad Rzeszutek Wilk wrote:
> So if we use an mailing list internally..
> > * Applicants and current members must submit a statement saying that
they
> > have
> > read, understand, and will abide by this process document.
> 
> Are the folks on the internal mailing list bound by this as well? Meaning
> that if a new person would like to join the internal mailing list they
> need to have read, understood, etc the process document?
I understood this to mean that the Organisation was agreeing to abide by
it, which implies a duty to ensure that anyone with that organisation
who is exposed to confidential information keeps it confidential. One
obvious way to implement that would be the company to internally require
new people to read and agree to the process document, but Xen.org need
not be involved in that.

It''s not that dissimilar to how NDAs work in general I think.
> I would presume so, but you are not stating it here nor:
> 
> http://wiki.xen.org/wiki/Security_vulnerability_process_draft
> 
> So what is driving the ''alias'' requirement?
There''s no reason for Xen.org to be involved in the internals of each
organisation''s security team. Apart from the management overhead on our
side it can also lead to situations where there are gaps in the coverage
as people come and go but because the company cannot (easily) see the
subscriber list on our end.

Ian.

Dropping -announce.

On Mon, 2013-01-07 at 16:37 +0000, Konrad Rzeszutek Wilk wrote:
> So if we use an mailing list internally..
> > * Applicants and current members must submit a statement saying that
they
> > have
> > read, understand, and will abide by this process document.
> 
> Are the folks on the internal mailing list bound by this as well? Meaning
> that if a new person would like to join the internal mailing list they
> need to have read, understood, etc the process document?
I understood this to mean that the Organisation was agreeing to abide by
it, which implies a duty to ensure that anyone with that organisation
who is exposed to confidential information keeps it confidential. One
obvious way to implement that would be the company to internally require
new people to read and agree to the process document, but Xen.org need
not be involved in that.

It''s not that dissimilar to how NDAs work in general I think.
> I would presume so, but you are not stating it here nor:
> 
> http://wiki.xen.org/wiki/Security_vulnerability_process_draft
> 
> So what is driving the ''alias'' requirement?
There''s no reason for Xen.org to be involved in the internals of each
organisation''s security team. Apart from the management overhead on our
side it can also lead to situations where there are gaps in the coverage
as people come and go but because the company cannot (easily) see the
subscriber list on our end.

Ian.

On Mon, Jan 07, 2013 at 04:46:19PM +0000, Ian Campbell
wrote:
> Dropping -announce.
> 
> On Mon, 2013-01-07 at 16:37 +0000, Konrad Rzeszutek Wilk wrote:
> 
> > So if we use an mailing list internally..
> > > * Applicants and current members must submit a statement saying
that they
> > > have
> > > read, understand, and will abide by this process document.
> > 
> > Are the folks on the internal mailing list bound by this as well?
Meaning
> > that if a new person would like to join the internal mailing list they
> > need to have read, understood, etc the process document?
> 
> I understood this to mean that the Organisation was agreeing to abide by
> it, which implies a duty to ensure that anyone with that organisation
> who is exposed to confidential information keeps it confidential. One
> obvious way to implement that would be the company to internally require
> new people to read and agree to the process document, but Xen.org need
> not be involved in that.
> 
> It''s not that dissimilar to how NDAs work in general I think.
Except that you don''t have to mail out the forms :-)
> 
> > I would presume so, but you are not stating it here nor:
> > 
> > http://wiki.xen.org/wiki/Security_vulnerability_process_draft
> > 
> > So what is driving the ''alias'' requirement?
> 
> There''s no reason for Xen.org to be involved in the internals of
each
> organisation''s security team. Apart from the management overhead
on our
> side it can also lead to situations where there are gaps in the coverage
> as people come and go but because the company cannot (easily) see the
> subscriber list on our end.

On Mon, Jan 07, 2013 at 04:46:19PM +0000, Ian Campbell
wrote:
> Dropping -announce.
> 
> On Mon, 2013-01-07 at 16:37 +0000, Konrad Rzeszutek Wilk wrote:
> 
> > So if we use an mailing list internally..
> > > * Applicants and current members must submit a statement saying
that they
> > > have
> > > read, understand, and will abide by this process document.
> > 
> > Are the folks on the internal mailing list bound by this as well?
Meaning
> > that if a new person would like to join the internal mailing list they
> > need to have read, understood, etc the process document?
> 
> I understood this to mean that the Organisation was agreeing to abide by
> it, which implies a duty to ensure that anyone with that organisation
> who is exposed to confidential information keeps it confidential. One
> obvious way to implement that would be the company to internally require
> new people to read and agree to the process document, but Xen.org need
> not be involved in that.
> 
> It''s not that dissimilar to how NDAs work in general I think.
Except that you don''t have to mail out the forms :-)
> 
> > I would presume so, but you are not stating it here nor:
> > 
> > http://wiki.xen.org/wiki/Security_vulnerability_process_draft
> > 
> > So what is driving the ''alias'' requirement?
> 
> There''s no reason for Xen.org to be involved in the internals of
each
> organisation''s security team. Apart from the management overhead
on our
> side it can also lead to situations where there are gaps in the coverage
> as people come and go but because the company cannot (easily) see the
> subscriber list on our end.

On Mon, 2013-01-07 at 19:12 +0000, Konrad Rzeszutek Wilk
wrote:
> On Mon, Jan 07, 2013 at 04:46:19PM +0000, Ian Campbell wrote:
> > Dropping -announce.
> > 
> > On Mon, 2013-01-07 at 16:37 +0000, Konrad Rzeszutek Wilk wrote:
> > 
> > > So if we use an mailing list internally..
> > > > * Applicants and current members must submit a statement
saying that they
> > > > have
> > > > read, understand, and will abide by this process document.
> > > 
> > > Are the folks on the internal mailing list bound by this as well?
Meaning
> > > that if a new person would like to join the internal mailing list
they
> > > need to have read, understood, etc the process document?
> > 
> > I understood this to mean that the Organisation was agreeing to abide
by
> > it, which implies a duty to ensure that anyone with that organisation
> > who is exposed to confidential information keeps it confidential. One
> > obvious way to implement that would be the company to internally
require
> > new people to read and agree to the process document, but Xen.org need
> > not be involved in that.
> > 
> > It''s not that dissimilar to how NDAs work in general I think.
> 
> Except that you don''t have to mail out the forms :-)
Perhaps the wording could be tweaked to make it clearer that the
*organisation* is agreeing to the policy and to taking on the
responsibility of ensuring that any members/employees of that
organisation who come into contact with confidential information will
abide by it too.

Ian.

On Mon, 2013-01-07 at 19:12 +0000, Konrad Rzeszutek Wilk
wrote:
> On Mon, Jan 07, 2013 at 04:46:19PM +0000, Ian Campbell wrote:
> > Dropping -announce.
> > 
> > On Mon, 2013-01-07 at 16:37 +0000, Konrad Rzeszutek Wilk wrote:
> > 
> > > So if we use an mailing list internally..
> > > > * Applicants and current members must submit a statement
saying that they
> > > > have
> > > > read, understand, and will abide by this process document.
> > > 
> > > Are the folks on the internal mailing list bound by this as well?
Meaning
> > > that if a new person would like to join the internal mailing list
they
> > > need to have read, understood, etc the process document?
> > 
> > I understood this to mean that the Organisation was agreeing to abide
by
> > it, which implies a duty to ensure that anyone with that organisation
> > who is exposed to confidential information keeps it confidential. One
> > obvious way to implement that would be the company to internally
require
> > new people to read and agree to the process document, but Xen.org need
> > not be involved in that.
> > 
> > It''s not that dissimilar to how NDAs work in general I think.
> 
> Except that you don''t have to mail out the forms :-)
Perhaps the wording could be tweaked to make it clearer that the
*organisation* is agreeing to the policy and to taking on the
responsibility of ensuring that any members/employees of that
organisation who come into contact with confidential information will
abide by it too.

Ian.

On 08/01/13 08:56, Ian Campbell wrote:
> On Mon, 2013-01-07 at 19:12 +0000, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jan 07, 2013 at 04:46:19PM +0000, Ian Campbell wrote:
>>> Dropping -announce.
>>>
>>> On Mon, 2013-01-07 at 16:37 +0000, Konrad Rzeszutek Wilk wrote:
>>>
>>>> So if we use an mailing list internally..
>>>>> * Applicants and current members must submit a statement
saying that they
>>>>> have
>>>>> read, understand, and will abide by this process document.
>>>> Are the folks on the internal mailing list bound by this as
well? Meaning
>>>> that if a new person would like to join the internal mailing
list they
>>>> need to have read, understood, etc the process document?
>>> I understood this to mean that the Organisation was agreeing to
abide by
>>> it, which implies a duty to ensure that anyone with that
organisation
>>> who is exposed to confidential information keeps it confidential.
One
>>> obvious way to implement that would be the company to internally
require
>>> new people to read and agree to the process document, but Xen.org
need
>>> not be involved in that.
>>>
>>> It''s not that dissimilar to how NDAs work in general I
think.
>> Except that you don''t have to mail out the forms :-)
> Perhaps the wording could be tweaked to make it clearer that the
> *organisation* is agreeing to the policy and to taking on the
> responsibility of ensuring that any members/employees of that
> organisation who come into contact with confidential information will
> abide by it too.
I''ll take a look at seeing if I can make the wording clearer regarding
this.

  -George

On 08/01/13 08:56, Ian Campbell wrote:
> On Mon, 2013-01-07 at 19:12 +0000, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jan 07, 2013 at 04:46:19PM +0000, Ian Campbell wrote:
>>> Dropping -announce.
>>>
>>> On Mon, 2013-01-07 at 16:37 +0000, Konrad Rzeszutek Wilk wrote:
>>>
>>>> So if we use an mailing list internally..
>>>>> * Applicants and current members must submit a statement
saying that they
>>>>> have
>>>>> read, understand, and will abide by this process document.
>>>> Are the folks on the internal mailing list bound by this as
well? Meaning
>>>> that if a new person would like to join the internal mailing
list they
>>>> need to have read, understood, etc the process document?
>>> I understood this to mean that the Organisation was agreeing to
abide by
>>> it, which implies a duty to ensure that anyone with that
organisation
>>> who is exposed to confidential information keeps it confidential.
One
>>> obvious way to implement that would be the company to internally
require
>>> new people to read and agree to the process document, but Xen.org
need
>>> not be involved in that.
>>>
>>> It''s not that dissimilar to how NDAs work in general I
think.
>> Except that you don''t have to mail out the forms :-)
> Perhaps the wording could be tweaked to make it clearer that the
> *organisation* is agreeing to the policy and to taking on the
> responsibility of ensuring that any members/employees of that
> organisation who come into contact with confidential information will
> abide by it too.
I''ll take a look at seeing if I can make the wording clearer regarding
this.

  -George

OK, I''ve updated the section to make it clear that organizations are
committing to the disclosure policy and agree to ensure that their
members who come in contact with it abide by the policy.

I think we''re probably ready for the normal vote starting 15 April.

 -George

On Mon, Dec 17, 2012 at 12:58 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> After concluding our poll [1] about changes to the security
> discussion, we determined that "Pre-disclosure to software vendors and
> a wide set of users" was probably the best fit for the community.  A
> set of concrete changes to the policy have now been discussed on
> xen-devel [2] [3], and we seem to have converged on something everyone
> finds acceptable.
>
> We are now presenting these changes for public review.  The purpose of
> this review process is to allow feedback on the text which will be
> voted on, in accordance to the Xen.org governance procedure [3].  Our
> plan is to leave this up for review until the third week in January.
> Any substantial updates will be mentioned on the blog and will extend
> the review time.
>
> All feedback and discussion should happen in public on the xen-devel
> mailing list.  If you have any suggestions for how to improve the
> proposal, please e-mail the list, and cc George Dunlap (george dot
> dunlap at citrix.com).
>
> = Summary of the updates >
> As discussed on the xen-devel mailing list, expand eligibility of the
> pre-disclosure list to include any public hosting provider, as well
> as software project:
> * Change "Large hosting providers" to "Public hosting
providers"
> * Remove "widely-deployed" from vendors and distributors
> * Add rules of thumb for what constitutes "genuine"
> * Add an itemized list of information to be included in the application,
> to make expectations clear and (hopefully) applications more streamlined.
>
> The first will allow hosting providers of any size to join.
>
> The second will allow software projects and vendors of any size to join.
>
> The third and fourth will help describe exactly what criteria will be used
> to
> determine eligibility for 1 and 2.
>
> Additionally, this proposal adds the following requirements:
> * Applicants and current members must use an e-mail alias, not an
> individual''s
> e-mail
> * Applicants and current members must submit a statement saying that they
> have
> read, understand, and will abide by this process document.
>
> The new policy in its entirety can be found here:
>
> http://wiki.xen.org/wiki/Security_vulnerability_process_draft
>
> For comparison, the current policy can be found here:
>
> http://www.xen.org/projects/security_vulnerability_process.html
>
>
> [1]
> http://blog.xen.org/index.php/2012/08/23/disclosure-process-poll-results/
>
> [2] http://marc.info/?l=xen-devel&m=135300020310446
>
> [3] http://marc.info/?l=xen-devel&m=135455914107182
>
> [4] http://www.xen.org/projects/governance.html
>

OK, I''ve updated the section to make it clear that organizations are
committing to the disclosure policy and agree to ensure that their
members who come in contact with it abide by the policy.

I think we''re probably ready for the normal vote starting 15 April.

 -George

On Mon, Dec 17, 2012 at 12:58 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> After concluding our poll [1] about changes to the security
> discussion, we determined that "Pre-disclosure to software vendors and
> a wide set of users" was probably the best fit for the community.  A
> set of concrete changes to the policy have now been discussed on
> xen-devel [2] [3], and we seem to have converged on something everyone
> finds acceptable.
>
> We are now presenting these changes for public review.  The purpose of
> this review process is to allow feedback on the text which will be
> voted on, in accordance to the Xen.org governance procedure [3].  Our
> plan is to leave this up for review until the third week in January.
> Any substantial updates will be mentioned on the blog and will extend
> the review time.
>
> All feedback and discussion should happen in public on the xen-devel
> mailing list.  If you have any suggestions for how to improve the
> proposal, please e-mail the list, and cc George Dunlap (george dot
> dunlap at citrix.com).
>
> = Summary of the updates >
> As discussed on the xen-devel mailing list, expand eligibility of the
> pre-disclosure list to include any public hosting provider, as well
> as software project:
> * Change "Large hosting providers" to "Public hosting
providers"
> * Remove "widely-deployed" from vendors and distributors
> * Add rules of thumb for what constitutes "genuine"
> * Add an itemized list of information to be included in the application,
> to make expectations clear and (hopefully) applications more streamlined.
>
> The first will allow hosting providers of any size to join.
>
> The second will allow software projects and vendors of any size to join.
>
> The third and fourth will help describe exactly what criteria will be used
> to
> determine eligibility for 1 and 2.
>
> Additionally, this proposal adds the following requirements:
> * Applicants and current members must use an e-mail alias, not an
> individual''s
> e-mail
> * Applicants and current members must submit a statement saying that they
> have
> read, understand, and will abide by this process document.
>
> The new policy in its entirety can be found here:
>
> http://wiki.xen.org/wiki/Security_vulnerability_process_draft
>
> For comparison, the current policy can be found here:
>
> http://www.xen.org/projects/security_vulnerability_process.html
>
>
> [1]
> http://blog.xen.org/index.php/2012/08/23/disclosure-process-poll-results/
>
> [2] http://marc.info/?l=xen-devel&m=135300020310446
>
> [3] http://marc.info/?l=xen-devel&m=135455914107182
>
> [4] http://www.xen.org/projects/governance.html
>

On Mon, 2012-12-17 at 12:58 +0000, George Dunlap wrote:
> * Applicants and current members must use an e-mail alias, not an
> individual''s e-mail 
An interesting wrinkle with this has come up a couple of times recently
(and at last once long ago which we''d all forgotten about):

The security team aliases of most distros at least include a bunch of
people charged with security support for the distro generally but not
usually, except by coincidence, the actual Xen package maintainer.

We''ve had a couple of distro package maintainers ask to be on the list
in their own right in addition to the relevant security team.

Asking them to setup xen-security-team@distro.org seems a bit of a
burden but the existing package aliases are not necessarily private e.g.
in Debian the xen package''s maintainer field is set to a public mailing
list, which is not uncommon in Debian and which causes stuff sent to
xen@packages.debian.org (the canonical way to mail a package maintainer)
to go to the list.

In the past we (the security team) have accepted these requests (after
checking with the relevant security team that this is ok) but the above
change would suggest that we should not.

One option which we have is to stick by the requirement to only list
aliases and request that the relevant security team forward advisories
discussion etc to the maintainer as they feel necessary. Distro security
teams do this anyway in many cases but it seems a bit silly to stop them
from delegating to the maintainer and "getting out of the way" in
cases
where they want to.

We could perhaps weaken the requirement slightly and say that every
organisation must list at least one e-mail alias but that individuals
will be accepted, perhaps with a list of requirements, such as:
      * clearly associated with a particular organisation
      * cleared by that organisations alias to be on the list
      * there is an obvious reason why the individual cannot be on the
        alias (it''s a generic distro alias being pretty obvious)

(obviously putting the word obvious in the actual guidelines would be a
recipe for interminably long threads about what is obvious, but
obviously you get the gist)

Ian.

On 15/04/13 15:55, Ian Campbell wrote:
>
> Asking them to setup xen-security-team@distro.org seems a bit of a
> burden
I''m just curious, is it really that much of a burden?  If Debian, for 
example, already has infrastructure to accept 
"<package>@packages.debian.org", how much extra work is it to
add
"<package>-security@debian.org"?

I''m not necessarily opposed to the exception, but I''m not 100%
sure it''s
that necessary.

  -George

On Tue, 2013-04-16 at 14:05 +0100, George Dunlap wrote:
> On 15/04/13 15:55, Ian Campbell wrote:
> >
> > Asking them to setup xen-security-team@distro.org seems a bit of a
> > burden
> 
> I''m just curious, is it really that much of a burden?  If Debian,
for
> example, already has infrastructure to accept 
> "<package>@packages.debian.org", how much extra work is it
to add
> "<package>-security@debian.org"?
For just one $package its probably still a moderate amount of work. I
would guess that it would require coordination with the DSA (Debian Sys
Admins, or whoever controls mx.debian.org and mx.packages.debian.org) to
setup the new alias and track/manage who the real maintainers is/are for
$package over time and changes etc. Remember that part of the problem
here is that the maintainer field can be and for better or worse of is
set to a public mailing list so there would need to be some rounds of
discussion etc about what the correct membership of the list should be
(use the changed-by field, use the uploaders field?). Packages are not
necessarily very consistent in these areas...

Now maybe the generic any $package variant of that would be a useful
thing for a distro to have but that would be even more work to actually
make it useful and it would be hard to guarantee that it remained
private for any given package (which somewhat defeats the purpose!)

Ian.

On Mon, Apr 08, 2013 at 12:24:11PM +0100, George Dunlap
wrote:
> OK, I''ve updated the section to make it clear that organizations
are
> committing to the disclosure policy and agree to ensure that their
> members who come in contact with it abide by the policy.
> 
> I think we''re probably ready for the normal vote starting 15
April.
Hi George,

Thanks for the update. Before we have a call for a vote I think it''d
be good to produce another redline version of the policy so it''s a bit
more clear what''s changing. What do you think?

Also, Lars added an item to the May hackathon wiki
(http://tiny.cc/vtwsvw) to discuss other aspects of the process that
might should be included in the policy. Should we defer voting on a
draft until after the hackathon?

Matt

On Mon, Apr 08, 2013 at 12:24:11PM +0100, George Dunlap
wrote:
> OK, I''ve updated the section to make it clear that organizations
are
> committing to the disclosure policy and agree to ensure that their
> members who come in contact with it abide by the policy.
> 
> I think we''re probably ready for the normal vote starting 15
April.
Hi George,

Thanks for the update. Before we have a call for a vote I think it''d
be good to produce another redline version of the policy so it''s a bit
more clear what''s changing. What do you think?

Also, Lars added an item to the May hackathon wiki
(http://tiny.cc/vtwsvw) to discuss other aspects of the process that
might should be included in the policy. Should we defer voting on a
draft until after the hackathon?

Matt

On Tue, 2013-04-16 at 15:13 +0100, Ian Campbell wrote:
> On Tue, 2013-04-16 at 14:05 +0100, George Dunlap wrote:
> > On 15/04/13 15:55, Ian Campbell wrote:
> > >
> > > Asking them to setup xen-security-team@distro.org seems a bit of
a
> > > burden
> > 
> > I''m just curious, is it really that much of a burden?  If
Debian, for
> > example, already has infrastructure to accept 
> > "<package>@packages.debian.org", how much extra work
is it to add
> > "<package>-security@debian.org"?
> 
> For just one $package its probably still a moderate amount of work. I
Ian J pointed out to me IRL that this is the sort of thing alioth (the
Debian Source/FusionForge instance) ought to be able to provide and I
can see an interface which purports to allow me to create a private list
on there (but I''ve not tried it).

Not sure about other distros but this seems to solve it for Debian at
least.

Ian.

On Fri, Apr 19, 2013 at 7:56 PM, Matt Wilson <msw@amazon.com>
wrote:
> On Mon, Apr 08, 2013 at 12:24:11PM +0100, George Dunlap wrote:
>> OK, I''ve updated the section to make it clear that
organizations are
>> committing to the disclosure policy and agree to ensure that their
>> members who come in contact with it abide by the policy.
>>
>> I think we''re probably ready for the normal vote starting 15
April.
>
> Hi George,
>
> Thanks for the update. Before we have a call for a vote I think
it''d
> be good to produce another redline version of the policy so it''s a
bit
> more clear what''s changing. What do you think?
I assume by "redline" you mean with the changes highlighted somehow?

That sounds like a good plan.  I was mainly waiting until the Linux
Foundation news settled down a bit, and then I was going to start the
voting process.
> Also, Lars added an item to the May hackathon wiki
> (http://tiny.cc/vtwsvw) to discuss other aspects of the process that
> might should be included in the policy. Should we defer voting on a
> draft until after the hackathon?
I''m willing to consider it, but I really don''t think
it''s necessary.
There has been ample time for people to reflect on and share their
views, and the process probably should have been voted on in February,
if I was better at multitasking. :-)

 -George

On Fri, Apr 19, 2013 at 7:56 PM, Matt Wilson <msw@amazon.com>
wrote:
> On Mon, Apr 08, 2013 at 12:24:11PM +0100, George Dunlap wrote:
>> OK, I''ve updated the section to make it clear that
organizations are
>> committing to the disclosure policy and agree to ensure that their
>> members who come in contact with it abide by the policy.
>>
>> I think we''re probably ready for the normal vote starting 15
April.
>
> Hi George,
>
> Thanks for the update. Before we have a call for a vote I think
it''d
> be good to produce another redline version of the policy so it''s a
bit
> more clear what''s changing. What do you think?
I assume by "redline" you mean with the changes highlighted somehow?

That sounds like a good plan.  I was mainly waiting until the Linux
Foundation news settled down a bit, and then I was going to start the
voting process.
> Also, Lars added an item to the May hackathon wiki
> (http://tiny.cc/vtwsvw) to discuss other aspects of the process that
> might should be included in the policy. Should we defer voting on a
> draft until after the hackathon?
I''m willing to consider it, but I really don''t think
it''s necessary.
There has been ample time for people to reflect on and share their
views, and the process probably should have been voted on in February,
if I was better at multitasking. :-)

 -George

On Tue, 2013-04-23 at 10:37 +0100, George Dunlap wrote:
> > Also, Lars added an item to the May hackathon wiki
> > (http://tiny.cc/vtwsvw) to discuss other aspects of the process that
> > might should be included in the policy. Should we defer voting on a
> > draft until after the hackathon?
> 
> I''m willing to consider it, but I really don''t think
it''s necessary.
Also the hackathon is going to be somewhat self selecting towards
developers only, whereas this is a discussion/issue into which the user
community has a stake.

Ian

On Tue, 2013-04-23 at 10:37 +0100, George Dunlap wrote:
> > Also, Lars added an item to the May hackathon wiki
> > (http://tiny.cc/vtwsvw) to discuss other aspects of the process that
> > might should be included in the policy. Should we defer voting on a
> > draft until after the hackathon?
> 
> I''m willing to consider it, but I really don''t think
it''s necessary.
Also the hackathon is going to be somewhat self selecting towards
developers only, whereas this is a discussion/issue into which the user
community has a stake.

Ian

On 19/04/13 20:41, Ian Campbell wrote:
> On Tue, 2013-04-16 at 15:13 +0100, Ian Campbell wrote:
>> On Tue, 2013-04-16 at 14:05 +0100, George Dunlap wrote:
>>> On 15/04/13 15:55, Ian Campbell wrote:
>>>> Asking them to setup xen-security-team@distro.org seems a bit
of a
>>>> burden
>>> I''m just curious, is it really that much of a burden?  If
Debian, for
>>> example, already has infrastructure to accept
>>> "<package>@packages.debian.org", how much extra
work is it to add
>>> "<package>-security@debian.org"?
>> For just one $package its probably still a moderate amount of work. I
> Ian J pointed out to me IRL that this is the sort of thing alioth (the
> Debian Source/FusionForge instance) ought to be able to provide and I
> can see an interface which purports to allow me to create a private list
> on there (but I''ve not tried it).
>
> Not sure about other distros but this seems to solve it for Debian at
> least.
How about the following:

The addition of individual e-mail addresses for
       an organization in addition to the organizational e-mail address
       will be considered in exceptional circumstances; for example, if
       the maintainer for the xen package is not on the organization''s
       security e-mail list, and either maintaining a separate list or
       having those on the list act as an intermediary would be too
       onerous.

  -George

On 24/04/13 12:02, George Dunlap wrote:
> On 19/04/13 20:41, Ian Campbell wrote:
>> On Tue, 2013-04-16 at 15:13 +0100, Ian Campbell wrote:
>>> On Tue, 2013-04-16 at 14:05 +0100, George Dunlap wrote:
>>>> On 15/04/13 15:55, Ian Campbell wrote:
>>>>> Asking them to setup xen-security-team@distro.org seems a
bit of a
>>>>> burden
>>>> I''m just curious, is it really that much of a burden? 
If Debian, for
>>>> example, already has infrastructure to accept
>>>> "<package>@packages.debian.org", how much extra
work is it to add
>>>> "<package>-security@debian.org"?
>>> For just one $package its probably still a moderate amount of work.
I
>> Ian J pointed out to me IRL that this is the sort of thing alioth (the
>> Debian Source/FusionForge instance) ought to be able to provide and I
>> can see an interface which purports to allow me to create a private
list
>> on there (but I''ve not tried it).
>>
>> Not sure about other distros but this seems to solve it for Debian at
>> least.
> How about the following:
>
> The addition of individual e-mail addresses for
>         an organization in addition to the organizational e-mail address
>         will be considered in exceptional circumstances; for example, if
>         the maintainer for the xen package is not on the
organization''s
>         security e-mail list, and either maintaining a separate list or
>         having those on the list act as an intermediary would be too
>         onerous.
Ping?

I''d like to get the vote started on this in the next week or two.

  -George

On Wed, 2013-05-01 at 16:31 +0100, George Dunlap wrote:
> On 24/04/13 12:02, George Dunlap wrote:
> > On 19/04/13 20:41, Ian Campbell wrote:
> >> On Tue, 2013-04-16 at 15:13 +0100, Ian Campbell wrote:
> >>> On Tue, 2013-04-16 at 14:05 +0100, George Dunlap wrote:
> >>>> On 15/04/13 15:55, Ian Campbell wrote:
> >>>>> Asking them to setup xen-security-team@distro.org
seems a bit of a
> >>>>> burden
> >>>> I''m just curious, is it really that much of a
burden?  If Debian, for
> >>>> example, already has infrastructure to accept
> >>>> "<package>@packages.debian.org", how much
extra work is it to add
> >>>> "<package>-security@debian.org"?
> >>> For just one $package its probably still a moderate amount of
work. I
> >> Ian J pointed out to me IRL that this is the sort of thing alioth
(the
> >> Debian Source/FusionForge instance) ought to be able to provide
and I
> >> can see an interface which purports to allow me to create a
private list
> >> on there (but I''ve not tried it).
> >>
> >> Not sure about other distros but this seems to solve it for Debian
at
> >> least.
> > How about the following:
> >
> > The addition of individual e-mail addresses for
> >         an organization in addition to the organizational e-mail
address
> >         will be considered in exceptional circumstances; for example,
if
> >         the maintainer for the xen package is not on the
organization''s
> >         security e-mail list, and either maintaining a separate list
or
> >         having those on the list act as an intermediary would be too
> >         onerous.
> 
> Ping?
Sorry, thought I''d replied.

Given that Ian J has pointed me to Alioth private lists I''m no longer
concerned about this from Debian''s PoV. I don''t really know if
this is
going to be an issue for other distros or not -- I suppose I''m inclined
to feel that if Debian can manage it so can they.

Ian

On 01/05/13 16:37, Ian Campbell wrote:
> On Wed, 2013-05-01 at 16:31 +0100, George Dunlap wrote:
>> On 24/04/13 12:02, George Dunlap wrote:
>>> On 19/04/13 20:41, Ian Campbell wrote:
>>>> On Tue, 2013-04-16 at 15:13 +0100, Ian Campbell wrote:
>>>>> On Tue, 2013-04-16 at 14:05 +0100, George Dunlap wrote:
>>>>>> On 15/04/13 15:55, Ian Campbell wrote:
>>>>>>> Asking them to setup xen-security-team@distro.org
seems a bit of a
>>>>>>> burden
>>>>>> I''m just curious, is it really that much of a
burden?  If Debian, for
>>>>>> example, already has infrastructure to accept
>>>>>> "<package>@packages.debian.org", how
much extra work is it to add
>>>>>> "<package>-security@debian.org"?
>>>>> For just one $package its probably still a moderate amount
of work. I
>>>> Ian J pointed out to me IRL that this is the sort of thing
alioth (the
>>>> Debian Source/FusionForge instance) ought to be able to provide
and I
>>>> can see an interface which purports to allow me to create a
private list
>>>> on there (but I''ve not tried it).
>>>>
>>>> Not sure about other distros but this seems to solve it for
Debian at
>>>> least.
>>> How about the following:
>>>
>>> The addition of individual e-mail addresses for
>>>          an organization in addition to the organizational e-mail
address
>>>          will be considered in exceptional circumstances; for
example, if
>>>          the maintainer for the xen package is not on the
organization''s
>>>          security e-mail list, and either maintaining a separate
list or
>>>          having those on the list act as an intermediary would be
too
>>>          onerous.
>> Ping?
> Sorry, thought I''d replied.
>
> Given that Ian J has pointed me to Alioth private lists I''m no
longer
> concerned about this from Debian''s PoV. I don''t really
know if this is
> going to be an issue for other distros or not -- I suppose I''m
inclined
> to feel that if Debian can manage it so can they.
OK -- and in any case that''s kind of a separate issue from the big one,
which is allowing more people to be on the list.

Thanks,
  -George