[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Mon, Nov 19, 2012 at 5:42 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.