From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [Xen-users] Security disclosure process discussion update Date: Mon, 7 Jan 2013 14:12:20 -0500 Message-ID: <20130107191220.GD8615@phenom.dumpdata.com> References: <20130107163701.GA6682@phenom.dumpdata.com> <1357577179.7989.133.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1357577179.7989.133.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 , "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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.