Xen devel - Nov 2012 - [PATCH RFC] Make all public hosting providers eligible for the pre-disclosure list

As discussed on the xen-devel mailing list, allow any public hosting
provider to join the pre-disclosure list:
* Change "Large hosting providers" to "Public hosting
providers"
* Add rule of thumb for what "public hosting provider" means
* Add an itemized list of information to be included in the application,
to make expectations clear and (hopefully) applications more streamlined.

NOTE: This RFC is meant to be a way to start a discussion on the exact
wording which will be voted on.  Once it has gone through review from
the xen-devel mailing list, I will post an "RC" and announce it on the
Xen blog, as well as on xen-users.  Once discussion seems to have
converged, I will post a "FINAL" one, which I will put up for a vote.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 security_vulnerability_process.html |   27 ++++++++++++++++++++-------
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/security_vulnerability_process.html
b/security_vulnerability_process.html
index e305371..35236c9 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -194,16 +194,18 @@ if(ns4)_d.write("<scr"+"ipt
type=text/javascript src=/globals/mmenuns4.js><\/scr
     addresses (ideally, role addresses) of the security response teams for
     significant Xen operators and distributors.</p>
     <p>This includes:<ul>
-      <li>Large-scale hosting providers;</li>
+      <li>Public hosting providers;</li>
       <li>Large-scale organisational users of Xen;</li>
       <li>Vendors of widely-deployed Xen-based systems;</li>
       <li>Distributors of widely-deployed operating systems with Xen
support.</li>
     </ul></p>
     <p>This includes both corporations and community
institutions.</p>
-    <p>Here as a rule of thumb "large scale" and "widely
deployed" means an
-    installed base of 300,000 or more Xen guests; other well-established
-    organisations with a mature security response process will be considered on
-    a case-by-case basis.</p>    
+    <p>Here as a rule of thumb, "public hosting provider" means
+    "selling virtualization services to the general public";
+    "large-scale" and "widely deployed" means an installed
base of
+    300,000 or more Xen guests.  Other well-established organisations
+    with a mature security response process will be considered on a
+    case-by-case basis.</p>
     <p>The list of entities on the pre-disclosure list is public. (Just
the list
     of projects and organisations, not the actual email addresses.)</p>  
     <p>If there is an embargo, the pre-disclosure list will receive
@@ -229,8 +231,19 @@ if(ns4)_d.write("<scr"+"ipt
type=text/javascript src=/globals/mmenuns4.js><\/scr
        <li>The planned disclosure date</li>
     </ul></p>
 
-    <p>Organisations who meet the criteria should contact security@xen if
they wish to receive pre-disclosure of advisories. Organisations should not
request subscription via the mailing list web interface, any such subscription
requests will be rejected and ignored.</p>
-    <p>Normally we would prefer that a role address be used for each
organisation, rather than one or more individual''s direct email
address. This helps to ensure that changes of personnel do not end up
effectively dropping an organisation from the list</p>
+    <p>Organisations who meet the criteria should contact security@xen
+      if they wish to receive pre-disclosure of advisories.  Please
+      include in the e-mail: <ul>
+	<li>The name of your organization</li>
+	<li>A brief description of why you fit the criteria</li>
+	<li>A security alias e-mail address (see below)</li>
+	<li>A web page with your security policy statement</li>
+	<li>If you are a public hosting provider, a web page with your public
rates</li>
+      </ul>
+      Organisations should not request subscription via the mailing
+      list web interface, any such subscription requests will be
+      rejected and ignored.</p>
+    <p>We prefer that a role address be used for each organisation,
rather than one or more individual''s direct email address. This helps
to ensure that changes of personnel do not end up effectively dropping an
organisation from the list</p>
 
     
     <h3>Organizations on the pre-disclosure list:</h3>
-- 
1.7.9.5

George Dunlap writes ("[Xen-devel] [PATCH RFC] Make all public hosting
providers eligible for the pre-disclosure list"):
> NOTE: This RFC is meant to be a way to start a discussion on the exact
> wording which will be voted on.  Once it has gone through review from
> the xen-devel mailing list, I will post an "RC" and announce it
on the
> Xen blog, as well as on xen-users.  Once discussion seems to have
> converged, I will post a "FINAL" one, which I will put up for a
vote.
Thanks for this.  Something along these lines is probably the best
compromise between the available options.

...
> -      <li>Large-scale hosting providers;</li>
> +      <li>Public hosting providers;</li>
>        <li>Large-scale organisational users of Xen;</li>
>        <li>Vendors of widely-deployed Xen-based systems;</li>
>        <li>Distributors of widely-deployed operating systems with
>        Xen support...
> +    <p>Here as a rule of thumb, "public hosting provider"
means
 +    "selling virtualization services to the general
public";
> +    "large-scale" and "widely deployed" means an
installed base of
> +    300,000 or more Xen guests.  Other well-established organisations
> +    with a mature security response process will be considered on a
> +    case-by-case basis.</p>
If we are allowing any cloud provider, not matter how small, to sign
up, then we should probably substantially relax the rules on software
vendors too.  I''m not sure exactly what the rule should be but
certainly we should be requiring no more than 1,000 deployed
instances.
> +    <p>We prefer that a role address be used for each organisation,
rather than one or more individual''s direct email address. This helps
to ensure that changes of personnel do not end up effectively dropping an
organisation from the list</p>
We should insist on this I think.  Otherwise it will be unmanageable.


I have another comment: given that predisclosure list members are
allowed to reveal the fact that there is an advisory and the release
date, would it be sensible for there to be a public list of
forthcoming public advisories ?

Ian.

On Fri, Nov 16, 2012 at 3:02 PM, Ian Jackson
<Ian.Jackson@eu.citrix.com>wrote:
> If we are allowing any cloud provider, not matter how small, to sign
> up, then we should probably substantially relax the rules on software
> vendors too.  I''m not sure exactly what the rule should be but
> certainly we should be requiring no more than 1,000 deployed
> instances.
>
What kind of vendors / projects might fit that kind of profile?

I suppose (for example) if there was a botique software dev house selling
high-value-add XenClient-like solutions to a relatively small number of
customers, it might make sense to allow them to join.

>
> > +    <p>We prefer that a role address be used for each
organisation,
> rather than one or more individual''s direct email address. This
helps to
> ensure that changes of personnel do not end up effectively dropping an
> organisation from the list</p>
>
> We should insist on this I think.  Otherwise it will be unmanageable.
>
Heh -- my early drafts did have this ("No personal e-mail addresses"),
but
I took it out to minimize the change.  I''m happy to put it back in. :-)

> I have another comment: given that predisclosure list members are
> allowed to reveal the fact that there is an advisory and the release
> date, would it be sensible for there to be a public list of
> forthcoming public advisories ?
>
That makes sense, but maybe should be in a separate patch?

 -George


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

George Dunlap writes ("Re: [Xen-devel] [PATCH RFC] Make all public hosting
providers eligible for the pre-disclosure list"):
> What kind of vendors / projects might fit that kind of profile?
>
> I suppose (for example) if there was a botique software dev house
> selling high-value-add XenClient-like solutions to a relatively
> small number of customers, it might make sense to allow them to
> join.
Yes.  Another possibility is more minor Linux distributions.

Many distros, particularly non-corporate ones, will not have reliable
usage statistics.  So we need some criterion for inclusion.

Ian.

On Thu, 2012-11-15 at 17:14 +0000, George Dunlap wrote:
> As discussed on the xen-devel mailing list, allow any public hosting
> provider to join the pre-disclosure list:
Thanks for doing this.
> * Change "Large hosting providers" to "Public hosting
providers"
> * Add rule of thumb for what "public hosting provider" means
> * Add an itemized list of information to be included in the application,
> to make expectations clear and (hopefully) applications more streamlined.
> 
> NOTE: This RFC is meant to be a way to start a discussion on the exact
> wording which will be voted on.  Once it has gone through review from
> the xen-devel mailing list, I will post an "RC" and announce it
on the
> Xen blog, as well as on xen-users.  Once discussion seems to have
> converged, I will post a "FINAL" one, which I will put up for a
vote.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>  security_vulnerability_process.html |   27 ++++++++++++++++++++-------
>  1 file changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/security_vulnerability_process.html
b/security_vulnerability_process.html
> index e305371..35236c9 100644
> --- a/security_vulnerability_process.html
> +++ b/security_vulnerability_process.html
> @@ -194,16 +194,18 @@ if(ns4)_d.write("<scr"+"ipt
type=text/javascript src=/globals/mmenuns4.js><\/scr
>      addresses (ideally, role addresses) of the security response teams for
>      significant Xen operators and distributors.</p>
>      <p>This includes:<ul>
> -      <li>Large-scale hosting providers;</li>
> +      <li>Public hosting providers;</li>
>        <li>Large-scale organisational users of Xen;</li>
>        <li>Vendors of widely-deployed Xen-based systems;</li>
>        <li>Distributors of widely-deployed operating systems with Xen
support.</li>
>      </ul></p>
>      <p>This includes both corporations and community
institutions.</p>
> -    <p>Here as a rule of thumb "large scale" and
"widely deployed" means an
> -    installed base of 300,000 or more Xen guests; other well-established
> -    organisations with a mature security response process will be
considered on
> -    a case-by-case basis.</p>    
> +    <p>Here as a rule of thumb, "public hosting provider"
means
> +    "selling virtualization services to the general public";
> +    "large-scale" and "widely deployed" means an
installed base of
> +    300,000 or more Xen guests.  Other well-established organisations
> +    with a mature security response process will be considered on a
> +    case-by-case basis.</p>
I agree with Ian that relaxing this for software vendors also seems the
correct thing to do.
>      <p>The list of entities on the pre-disclosure list is public.
(Just the list
>      of projects and organisations, not the actual email
addresses.)</p>
>      <p>If there is an embargo, the pre-disclosure list will receive
> @@ -229,8 +231,19 @@ if(ns4)_d.write("<scr"+"ipt
type=text/javascript src=/globals/mmenuns4.js><\/scr
>         <li>The planned disclosure date</li>
>      </ul></p>
>  
> -    <p>Organisations who meet the criteria should contact
security@xen if they wish to receive pre-disclosure of advisories. Organisations
should not request subscription via the mailing list web interface, any such
subscription requests will be rejected and ignored.</p>
> -    <p>Normally we would prefer that a role address be used for each
organisation, rather than one or more individual''s direct email
address. This helps to ensure that changes of personnel do not end up
effectively dropping an organisation from the list</p>
> +    <p>Organisations who meet the criteria should contact
security@xen
> +      if they wish to receive pre-disclosure of advisories.  Please
> +      include in the e-mail: <ul>
> +	<li>The name of your organization</li>
> +	<li>A brief description of why you fit the criteria</li>
> +	<li>A security alias e-mail address (see below)</li>
> +	<li>A web page with your security policy statement</li>
> +	<li>If you are a public hosting provider, a web page with your
public rates</li>
For the last two "a link to ...". Seems obvious but some people are
very
literal ;-)

I think it would be good to also include something like:
                <li>A statement to the effect that you have read this
                policy and agree to abide by the terms for inclusion in
                the list, specifically the requirements to regarding
                confidentiality during an embargo period</li>

Or something like that.

I wonder if we shouldn''t also include under the list of
"pre-disclosure
list members should not make available," include "Failure to adhere to
this will be grounds for removal from the list".

I suppose then we need an appeals process though. How about
"Reinstatement will require a post to the xen-devel mailing list
explaining the procedures which have been put in place to prevent any
further breach of confidentiality" + a three strikes rule (any org who
managed so mess this up three times isn''t likely to stay in business
long enough to require an appeals process against that ;-)).

Also, and I understand this is most likely taking things way too far, I
was wondering about requiring the request to be signed by a key which
itself has a signature from a key in the "strong
set" (http://pgp.cs.uu.nl/plot/) of PGP keys (implemented by me being
able to find a path from my key to it). This is just another hurdle
which serves to ensure that list members are in some sense legitimate.
(NB I''m not sure I buy this argument, surely there are corrupt types in
the strong set). This hurdle might be too big in practice? It doesn''t
seem so to me but then I hang around with a lot of Debian types ;-)

What are we going to do for existing members? Ask them to requalify by
some deadline? I wouldn''t normally bother but the statement about
agreeing to the confidentiality terms (if we do that) seems like a
worthwhile thing to require?
> +      </ul>
> +      Organisations should not request subscription via the mailing
> +      list web interface, any such subscription requests will be
> +      rejected and ignored.</p>
> +    <p>We prefer that a role address be used for each organisation,
rather than one or more individual''s direct email address. This helps
to ensure that changes of personnel do not end up effectively dropping an
organisation from the list</p>
Ack on /prefer/require/ suggestion.
>  
>      
>      <h3>Organizations on the pre-disclosure list:</h3>

Hi,

Firstly I would like to say that it''s great this conversation is
happening on the open list and that a wider set of organisations are
being considered.

On 16 November 2012 04:14, George Dunlap <george.dunlap@eu.citrix.com>
wrote:
> As discussed on the xen-devel mailing list, allow any public hosting
> provider to join the pre-disclosure list:
> * Change "Large hosting providers" to "Public hosting
providers"
> * Add rule of thumb for what "public hosting provider" means
> * Add an itemized list of information to be included in the application,
> to make expectations clear and (hopefully) applications more streamlined.
As a smaller but more specialized hosting provider (security concious
clientèle) I am really glad to hear this.

I think important information that should be forthcoming from service
providers wanting to join the pre-disclosure group would be:

a) How they consume Xen, be it via a vendor, distro packages of some
kind or whether they build and package their own. Those doing their
own packaging I feel should be given somewhat of a priority because
they aren''t able to rely on their vendor and instead must dedicate
resources to responding.
b) Their upgrade and security response procedures. It doesn''t make
sense for someone to be on the pre-disclosure list if they lack the
ability (or more importantly the requirement) to aggressively test and
push out security fixes.
c) Resources available to assist in testing security patches. This
might be a non-issue but I personally think it''s somewhat important
that groups on the pre-disclosure list are able to assist in testing
or reviewing patches, this improves the quality of said patches and
might allow a greater degree of vulnerability exploration. This is
however, largely my own opinion on what is considered fair
contribution in return for the privilege.

I think there should also be appropriate "guideline" points/criteria
that should be covered by other categories of organisations seeking to
join the pre-disclosure group.

Sorry if ideas along the lines of these have already been raised.
>
> NOTE: This RFC is meant to be a way to start a discussion on the exact
> wording which will be voted on.  Once it has gone through review from
> the xen-devel mailing list, I will post an "RC" and announce it
on the
> Xen blog, as well as on xen-users.  Once discussion seems to have
> converged, I will post a "FINAL" one, which I will put up for a
vote.
>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>  security_vulnerability_process.html |   27 ++++++++++++++++++++-------
>  1 file changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/security_vulnerability_process.html
b/security_vulnerability_process.html
> index e305371..35236c9 100644
> --- a/security_vulnerability_process.html
> +++ b/security_vulnerability_process.html
> @@ -194,16 +194,18 @@ if(ns4)_d.write("<scr"+"ipt
type=text/javascript src=/globals/mmenuns4.js><\/scr
>      addresses (ideally, role addresses) of the security response teams for
>      significant Xen operators and distributors.</p>
>      <p>This includes:<ul>
> -      <li>Large-scale hosting providers;</li>
> +      <li>Public hosting providers;</li>
>        <li>Large-scale organisational users of Xen;</li>
>        <li>Vendors of widely-deployed Xen-based systems;</li>
>        <li>Distributors of widely-deployed operating systems with Xen
support.</li>
>      </ul></p>
>      <p>This includes both corporations and community
institutions.</p>
> -    <p>Here as a rule of thumb "large scale" and
"widely deployed" means an
> -    installed base of 300,000 or more Xen guests; other well-established
> -    organisations with a mature security response process will be
considered on
> -    a case-by-case basis.</p>
> +    <p>Here as a rule of thumb, "public hosting provider"
means
> +    "selling virtualization services to the general public";
> +    "large-scale" and "widely deployed" means an
installed base of
> +    300,000 or more Xen guests.  Other well-established organisations
> +    with a mature security response process will be considered on a
> +    case-by-case basis.</p>
>      <p>The list of entities on the pre-disclosure list is public.
(Just the list
>      of projects and organisations, not the actual email
addresses.)</p>
>      <p>If there is an embargo, the pre-disclosure list will receive
> @@ -229,8 +231,19 @@ if(ns4)_d.write("<scr"+"ipt
type=text/javascript src=/globals/mmenuns4.js><\/scr
>         <li>The planned disclosure date</li>
>      </ul></p>
>
> -    <p>Organisations who meet the criteria should contact
security@xen if they wish to receive pre-disclosure of advisories. Organisations
should not request subscription via the mailing list web interface, any such
subscription requests will be rejected and ignored.</p>
> -    <p>Normally we would prefer that a role address be used for each
organisation, rather than one or more individual''s direct email
address. This helps to ensure that changes of personnel do not end up
effectively dropping an organisation from the list</p>
> +    <p>Organisations who meet the criteria should contact
security@xen
> +      if they wish to receive pre-disclosure of advisories.  Please
> +      include in the e-mail: <ul>
> +       <li>The name of your organization</li>
> +       <li>A brief description of why you fit the
criteria</li>
> +       <li>A security alias e-mail address (see below)</li>
> +       <li>A web page with your security policy statement</li>
> +       <li>If you are a public hosting provider, a web page with
your public rates</li>
> +      </ul>
> +      Organisations should not request subscription via the mailing
> +      list web interface, any such subscription requests will be
> +      rejected and ignored.</p>
> +    <p>We prefer that a role address be used for each organisation,
rather than one or more individual''s direct email address. This helps
to ensure that changes of personnel do not end up effectively dropping an
organisation from the list</p>
>
>
>      <h3>Organizations on the pre-disclosure list:</h3>
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

On Mon, 2012-11-19 at 21:29 +0000, Joseph Glanville
wrote:
> a) How they consume Xen, be it via a vendor, distro packages of some
> kind or whether they build and package their own. Those doing their
> own packaging I feel should be given somewhat of a priority because
> they aren''t able to rely on their vendor and instead must dedicate
> resources to responding.
I think we''ve previously discussed whether direct vs. indirect
consumers
should be on the list, but I don''t recall what the consensus/conclusion
(if any) was. Indirect consumers are not included today.

Since we allow people in the list to tell their consumers about the
existence of an issue (i.e. be ready on this day to deploy) I not sure
why indirect consumers would need to be or expect to be on the list (for
example we don''t consider allowing arbitrary distro users).
> b) Their upgrade and security response procedures. It doesn''t make
> sense for someone to be on the pre-disclosure list if they lack the
> ability (or more importantly the requirement) to aggressively test and
> push out security fixes.
At the very least they may be able to take advantage of the mitigations
which are often presented or just keep an eye out for suspicious goings
on in their systems.

I''m also not sure why it matters how aggressively they can test and
push. Two weeks is two weeks no matter how long it takes them to
actually get stuff out the door, so it is advantageous in terms of
ensuring that security fixes propagate as quickly as possible to have
such people on the list.

If they are incompetent or slow or their service is poor then that is
something for the market to decide on, not us via the security
pre-disclosure list.
> c) Resources available to assist in testing security patches. This
> might be a non-issue but I personally think it''s somewhat
important
> that groups on the pre-disclosure list are able to assist in testing
> or reviewing patches, this improves the quality of said patches and
> might allow a greater degree of vulnerability exploration. This is
> however, largely my own opinion on what is considered fair
> contribution in return for the privilege.
It is nice if people on the list can do this (more eyes are always
welcome) but it absolutely is not and should not be a requirement that
they be able to do so in order to receive notification of security
vulnerabilities.

The purpose of the list is to inform users of Xen security issues. It is
not intended only to benefit those who happen to be security savvy, or
developers or even particularly competent which is what your b) and c)
seem to be trying to achieve.

The consensus which I believe we saw from the community was that the
list should be more not less inclusive, while you appear to be
advocating that it should be more exclusive.

I also think we need to be careful about considering membership of this
list to be a privilege for which one must "pay" (whether in
"services"
or quid-pro-quo or whatever). It is a service which we should be
providing our users because it is the right thing to do for the Xen.org
community.
> I think there should also be appropriate "guideline"
points/criteria
> that should be covered by other categories of organisations seeking to
> join the pre-disclosure group.
That sounds like a good idea.
> Sorry if ideas along the lines of these have already been raised.

On Mon, Nov 19, 2012 at 5:42 PM, Ian Campbell
<Ian.Campbell@citrix.com>wrote:
> > +    <p>Here as a rule of thumb, "public hosting
provider" means
> > +    "selling virtualization services to the general
public";
> > +    "large-scale" and "widely deployed" means an
installed base of
> > +    300,000 or more Xen guests.  Other well-established organisations
> > +    with a mature security response process will be considered on a
> > +    case-by-case basis.</p>
>
> I agree with Ian that relaxing this for software vendors also seems the
> correct thing to do.
>
If we''re going to include software vendors, we need some simple
criteria to
define what a "real" software vendor is.  The idea of asking for a
link
from cloud providers pointing to public rates and a security policy, which
Ian Jackson proffered, was a good one.  I suppose we could do something
similar for software providers: a link to a web page with either
download-able install images, or prices, perhaps?

>
> > +     <li>A web page with your security policy
statement</li>
> > +     <li>If you are a public hosting provider, a web page with
your
> public rates</li>
>
> For the last two "a link to ...". Seems obvious but some people
are very
> literal ;-)
>
Ack.

> I think it would be good to also include something like:
>                 <li>A statement to the effect that you have read this
>                 policy and agree to abide by the terms for inclusion in
>                 the list, specifically the requirements to regarding
>                 confidentiality during an embargo period</li>
>
> Or something like that.
>
Ack.

> I wonder if we shouldn''t also include under the list of
"pre-disclosure
> list members should not make available," include "Failure to
adhere to
> this will be grounds for removal from the list".
>
> I suppose then we need an appeals process though. How about
> "Reinstatement will require a post to the xen-devel mailing list
> explaining the procedures which have been put in place to prevent any
> further breach of confidentiality" + a three strikes rule (any org who
> managed so mess this up three times isn''t likely to stay in
business
> long enough to require an appeals process against that ;-)).
>
I think this is a slightly separate topic -- I think it would be easier if
we handle criteria for inclusion separately from procedure for removal /
reinstatement.

> Also, and I understand this is most likely taking things way too far, I
> was wondering about requiring the request to be signed by a key which
> itself has a signature from a key in the "strong
> set" (http://pgp.cs.uu.nl/plot/) of PGP keys (implemented by me being
> able to find a path from my key to it). This is just another hurdle
> which serves to ensure that list members are in some sense legitimate.
> (NB I''m not sure I buy this argument, surely there are corrupt
types in
> the strong set). This hurdle might be too big in practice? It
doesn''t
> seem so to me but then I hang around with a lot of Debian types ;-)
>
Well that might work for open-source providers, but would it work for say,
Rackspace, Linode, Amazon?  Huawei?  Or another company like Citrix, whose
product team isn''t heavily involved in open-source community things?

It might be sensible to say that such a signature would be considered in
the application process -- that would allow small groups that are very
active in the OSS community to balance out large companies that can spend a
lot on marketing &c to make themselves known.

 -George


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

On Tue, 2012-11-27 at 12:05 +0000, George Dunlap wrote:
> On Mon, Nov 19, 2012 at 5:42 PM, Ian Campbell
> <Ian.Campbell@citrix.com> wrote:
>  
>         I wonder if we shouldn''t also include under the list of
"pre-disclosure
>         list members should not make available," include "Failure
to adhere to
>         this will be grounds for removal from the list".
>         
>         I suppose then we need an appeals process though. How about
>         "Reinstatement will require a post to the xen-devel mailing
list
>         explaining the procedures which have been put in place to prevent
any
>         further breach of confidentiality" + a three strikes rule (any
org who
>         managed so mess this up three times isn''t likely to stay
in business
>         long enough to require an appeals process against that ;-)).
> 
> I think this is a slightly separate topic -- I think it would be
> easier if we handle criteria for inclusion separately from procedure
> for removal / reinstatement.
OK.
 
>         Also, and I understand this is most likely taking things way too
far, I
>         was wondering about requiring the request to be signed by a key
which
>         itself has a signature from a key in the "strong
>         set" (http://pgp.cs.uu.nl/plot/) of PGP keys (implemented by
me being
>         able to find a path from my key to it). This is just another hurdle
>         which serves to ensure that list members are in some sense
legitimate.
>         (NB I''m not sure I buy this argument, surely there are
corrupt types in
>         the strong set). This hurdle might be too big in practice? It
doesn''t
>         seem so to me but then I hang around with a lot of Debian types ;-)
> 
> Well that might work for open-source providers, but would it work for
> say, Rackspace, Linode, Amazon?  Huawei?  Or another company like
> Citrix, whose product team isn''t heavily involved in open-source
> community things?
The PGP Web of Trust isn''t an OSS thing by any means.

We (security@) have easily had as many encrypted emails from the
commercial parts of various organisations as we have had from "OSS"
people.
> It might be sensible to say that such a signature would be considered
> in the application process -- that would allow small groups that are
> very active in the OSS community to balance out large companies that
> can spend a lot on marketing &c to make themselves known.
Yes, it could certainly be one of several criteria.
>  
>  -George
>

On Tue, Nov 27, 2012 at 12:05 PM, George Dunlap
<George.Dunlap@eu.citrix.com
> wrote:
> On Mon, Nov 19, 2012 at 5:42 PM, Ian Campbell
<Ian.Campbell@citrix.com>wrote:
>
>> > +    <p>Here as a rule of thumb, "public hosting
provider" means
>> > +    "selling virtualization services to the general
public";
>> > +    "large-scale" and "widely deployed" means
an installed base of
>> > +    300,000 or more Xen guests.  Other well-established
organisations
>> > +    with a mature security response process will be considered on
a
>> > +    case-by-case basis.</p>
>>
>> I agree with Ian that relaxing this for software vendors also seems the
>> correct thing to do.
>>
>
> If we''re going to include software vendors, we need some simple
criteria
> to define what a "real" software vendor is.  The idea of asking
for a link
> from cloud providers pointing to public rates and a security policy, which
> Ian Jackson proffered, was a good one.  I suppose we could do something
> similar for software providers: a link to a web page with either
> download-able install images, or prices, perhaps?
>
Thinking a bit more about this one -- if someone had (say) a Debian
derivative that looked like it was basically just a different default set
of packages -- IOW, a very small amount of effort to create and maintain --
that wouldn''t qualify for being on the list, right?  So it seems to me
like
"amount of effort spent" is kind of what we''re looking for,
right?  I mean,
if 2-3 developers are spending 3-4 hours per week each working on
something, then it''s clearly a project we could consider, even if
it''s
really small.  I''m sure that would include QubesOS, ArchLinux,
Edubuntu,
Scientific Linux, &c &c.  But if it''s one guy spending half an
hour every
six months, he doesn''t really need to be on the list I don''t
think.

This would be a "rule of thumb" or "guideline" rather than a
rule.

Thoughts?

 -George


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

On Mon, 2012-12-03 at 17:12 +0000, George Dunlap wrote:
> On Tue, Nov 27, 2012 at 12:05 PM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
>         On Mon, Nov 19, 2012 at 5:42 PM, Ian Campbell
>         <Ian.Campbell@citrix.com> wrote:
>         
>                 > +    <p>Here as a rule of thumb, "public
hosting
>                 provider" means
>                 > +    "selling virtualization services to the
general
>                 public";
>                 > +    "large-scale" and "widely
deployed" means an
>                 installed base of
>                 > +    300,000 or more Xen guests.  Other
>                 well-established organisations
>                 > +    with a mature security response process will be
>                 considered on a
>                 > +    case-by-case basis.</p>
>                 
>                 
>                 I agree with Ian that relaxing this for software
>                 vendors also seems the
>                 correct thing to do.
>         
>         If we''re going to include software vendors, we need some
>         simple criteria to define what a "real" software vendor
is.
>         The idea of asking for a link from cloud providers pointing to
>         public rates and a security policy, which Ian Jackson
>         proffered, was a good one.  I suppose we could do something
>         similar for software providers: a link to a web page with
>         either download-able install images, or prices, perhaps?
>         
> 
> Thinking a bit more about this one -- if someone had (say) a Debian
> derivative that looked like it was basically just a different default
> set of packages -- IOW, a very small amount of effort to create and
> maintain -- that wouldn''t qualify for being on the list, right? 
So it
> seems to me like "amount of effort spent" is kind of what
we''re
> looking for, right?  I mean, if 2-3 developers are spending 3-4 hours
> per week each working on something, then it''s clearly a project we
> could consider, even if it''s really small.  I''m sure that
would
> include QubesOS, ArchLinux, Edubuntu, Scientific Linux, &c &c.  But
if
> it''s one guy spending half an hour every six months, he
doesn''t really
> need to be on the list I don''t think.
Is "deviation from upstream" a factor at all?

e.g. is a Debian derivative just ships the Xen bits direct from Debian
then there doesn''t seem to be much call for them to be on the list,
they
can simply just ship the security update too. This would be true even if
they were dozens of engineers working full time.

On the other hand if they are packaging Xen themselves, or modifying the
Debian package substantially that would potentially be somewhat
different, even if they were small (like your above example).
> This would be a "rule of thumb" or "guideline" rather
than a rule.
Yes, I think most of these things will have to be.

I went looking for the linux-distros list inclusion criteria, in the
hopes we could just piggy back off that, but I can''t find it right now.

Ian.

On 03/12/12 17:26, Ian Campbell wrote:
> On Mon, 2012-12-03 at 17:12 +0000, George Dunlap wrote:
>> On Tue, Nov 27, 2012 at 12:05 PM, George Dunlap
>> <George.Dunlap@eu.citrix.com> wrote:
>>          On Mon, Nov 19, 2012 at 5:42 PM, Ian Campbell
>>          <Ian.Campbell@citrix.com> wrote:
>>          
>>                  > +    <p>Here as a rule of thumb,
"public hosting
>>                  provider" means
>>                  > +    "selling virtualization services to the
general
>>                  public";
>>                  > +    "large-scale" and "widely
deployed" means an
>>                  installed base of
>>                  > +    300,000 or more Xen guests.  Other
>>                  well-established organisations
>>                  > +    with a mature security response process will
be
>>                  considered on a
>>                  > +    case-by-case basis.</p>
>>                  
>>                  
>>                  I agree with Ian that relaxing this for software
>>                  vendors also seems the
>>                  correct thing to do.
>>          
>>          If we''re going to include software vendors, we need
some
>>          simple criteria to define what a "real" software
vendor is.
>>          The idea of asking for a link from cloud providers pointing to
>>          public rates and a security policy, which Ian Jackson
>>          proffered, was a good one.  I suppose we could do something
>>          similar for software providers: a link to a web page with
>>          either download-able install images, or prices, perhaps?
>>          
>>
>> Thinking a bit more about this one -- if someone had (say) a Debian
>> derivative that looked like it was basically just a different default
>> set of packages -- IOW, a very small amount of effort to create and
>> maintain -- that wouldn''t qualify for being on the list,
right?  So it
>> seems to me like "amount of effort spent" is kind of what
we''re
>> looking for, right?  I mean, if 2-3 developers are spending 3-4 hours
>> per week each working on something, then it''s clearly a
project we
>> could consider, even if it''s really small.  I''m sure
that would
>> include QubesOS, ArchLinux, Edubuntu, Scientific Linux, &c &c. 
But if
>> it''s one guy spending half an hour every six months, he
doesn''t really
>> need to be on the list I don''t think.
> Is "deviation from upstream" a factor at all?
>
> e.g. is a Debian derivative just ships the Xen bits direct from Debian
> then there doesn''t seem to be much call for them to be on the
list, they
> can simply just ship the security update too. This would be true even if
> they were dozens of engineers working full time.
I was going to say that if they''re not informed, there may be a longer 
turn-around time; but providers on the list are explicitly allowed to 
say that there *is* a vulnerability, and *when* the disclosure is 
scheduled to be, so if it''s just a matter of making the same bits 
available that Debian has made available, it shouldn''t be too long for 
those who are prepared.

But how much extra work would you need to do to qualify you for the 
list?  Suppose there''s a derivative with a single additional patch -- 
that will still require pulling in the source, potentially porting the 
patch, doing a re-build, and some basic re-testing -- that whole thing 
could take a day even for a well-funded project.

If the criteria is so small, and so easy to qualify (just re-build the 
package basically), I''m not sure it''s so useful to mention it.
> I went looking for the linux-distros list inclusion criteria, in the
> hopes we could just piggy back off that, but I can''t find it right
now.
I''ve got a draft I think is helpful; I''ll send a v2 and people
can see
what they think of it.

  -George