From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Cox Subject: Re: Security vulnerability process, and CVE-2012-0217 Date: Mon, 2 Jul 2012 16:13:50 +0100 Message-ID: <20120702161350.7cb94703@pyramind.ukuu.org.uk> References: <20448.49637.38489.246434@mariner.uk.xensource.com> <4FEB4BDD.5040205@goirand.fr> <1341237555.4625.93.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1341237555.4625.93.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: George Dunlap , Thomas Goirand , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org > It also supposes that there would be some way to police this separation > -- how could you tell if a software vendor had given unfair advantage to > their friends, and how could you tell which one it was in order to > "punish" them? You've equally got to deal with the vendors whose employees decide to tell their friends. Common sense will always apply. > The same problem exists if you allow service providers but insist that a > condition of membership is that they use the pre-disclosure period to > "prepare but not deploy" (i.e. to keep their hats separate). Other than > a suspicious wave of reboots across that providers infrastructure > (attributed to "routine maintenance") how would you know? The bad guys monitor this. The other way you'll know is when blackhats observe a given provider is immune to an exploit infeasibly fast. At which point that will slowly become general knowledge. Alan