Security disclosure process discussion update

Security disclosure process discussion update

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 2458 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 3189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Security disclosure process discussion update

[Konrad Rzeszutek Wilk]

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?

Re: [Xen-users] Security disclosure process discussion update

[Ian Campbell]

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.

Re: [Xen-users] Security disclosure process discussion update

[Konrad Rzeszutek Wilk]

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.

Re: [Xen-users] Security disclosure process discussion update

[Ian Campbell]

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.

Re: [Xen-users] Security disclosure process discussion update

[George Dunlap]

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

Re: Security disclosure process discussion update

[George Dunlap]

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
>

Re: [Xen-users] Security disclosure process discussion update

[Ian Campbell]

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.

Re: [Xen-users] Security disclosure process discussion update

[George Dunlap]

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

Re: [Xen-users] Security disclosure process discussion update

[Ian Campbell]

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.

Re: [Xen-users] Security disclosure process discussion update

[Ian Campbell]

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.

Re: [Xen-users] Security disclosure process discussion update

[George Dunlap]

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

Re: [Xen-users] Security disclosure process discussion update

[George Dunlap]

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

Re: [Xen-users] Security disclosure process discussion update

[Ian Campbell]

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

Re: [Xen-users] Security disclosure process discussion update

[George Dunlap]

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

Re: Security disclosure process discussion update

[Matt Wilson]

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

Re: Security disclosure process discussion update

[George Dunlap]

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

Re: Security disclosure process discussion update

[Ian Campbell]

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