Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2015-02-12 Thread Lars Kurth
Hi all, I am assuming this question is in effect resolved. The proposed (and agreed) text basically states that security advisories state whether people will be allowed to deploy. The underlying assumption is that usually this is the case, unless there is a very good reason not to. How the secur

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2015-01-20 Thread George Dunlap
On Mon, Jan 19, 2015 at 8:36 PM, James McKenzie wrote: > On 29/10/14 13:27, James Bulpin wrote: >> >> George Dunlap writes ("Security policy ambiguities - XSA-108 process >> post-mortem"): >>> >>> [snip] >>> >>> As far as I can tell we basically have the following options: >>> >>> 1. Never allow p

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2015-01-20 Thread Jan Beulich
>>> On 19.01.15 at 21:36, wrote: > On 29/10/14 13:27, James Bulpin wrote: >> George Dunlap writes ("Security policy ambiguities - XSA-108 process > post-mortem"): >>> [snip] >>> >>> As far as I can tell we basically have the following options: >>> >>> 1. Never allow people to deploy during the em

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2015-01-19 Thread James McKenzie
On 29/10/14 13:27, James Bulpin wrote: George Dunlap writes ("Security policy ambiguities - XSA-108 process post-mortem"): [snip] As far as I can tell we basically have the following options: 1. Never allow people to deploy during the embargo period. 2. Always allow people to deploy during t

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2015-01-16 Thread Ian Jackson
Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > On 10 Nov 2014, at 18:01, Ian Jackson wrote: ... > > The Security Team will impose deployment restrictions only insofar > > as it is necessary to prevent the exposu

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-14 Thread Lars Kurth
On 14 Nov 2014, at 12:50, Ian Jackson wrote: > Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 > process post-mortem"): >> I do have one question. What led us to publish an XSA number on >> http://xenbits.xen.org/xsa/ in the way we

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-14 Thread Ian Jackson
Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > I do have one question. What led us to publish an XSA number on > http://xenbits.xen.org/xsa/ in the way we do now? As far as I can tell, > CVE numbers are not published no

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-14 Thread Lars Kurth
On 10 Nov 2014, at 18:01, Ian Jackson wrote: > Having gone through the thread, I've prepared a three-part new > proposal email. > > I. Deployment with Security Team Permission > II. Predisclosure list memembership > III. Information sharing > IV. Fixes which seem to have rough consensus as they

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-13 Thread Ian Jackson
George Dunlap writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson > wrote: > > III. Information-sharing > > ... > > List members are allowed

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-12 Thread George Dunlap
On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson wrote: > Having gone through the thread, I've prepared a three-part new > proposal email. > > I. Deployment with Security Team Permission > II. Predisclosure list memembership > III. Information sharing > IV. Fixes which seem to have rough consensus as

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-11 Thread John Haxby
On 10/11/14 18:01, Ian Jackson wrote: > * Domain name(s) which you use to provide Xen software/services. This makes sense for a services provider but I'm not sure what it means for a distro. Is this intended to mean a download location for an installation image and updates?If it's a down

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-10 Thread George Dunlap
On Mon, Nov 10, 2014 at 5:29 PM, Ian Jackson wrote: > Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 > process post-mortem"): >> On this point in particular, back in 2012 [1] I suggested that all >> membership requests should be discus

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-10 Thread Ian Jackson
George Dunlap writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > On Mon, Nov 10, 2014 at 5:29 PM, Ian Jackson > > Such a system would (a) be unworkable in practice, because no-one > > really cares about this kind of tedious mak

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-10 Thread Ian Jackson
Having gone through the thread, I've prepared a three-part new proposal email. I. Deployment with Security Team Permission II. Predisclosure list memembership III. Information sharing IV. Fixes which seem to have rough consensus as they were Perhaps I should be checking the current web page out a

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-10 Thread Ian Jackson
Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > On Wed, Oct 22, 2014 at 02:05:38PM +0100, Lars Kurth wrote: > > The changes on the table are really more practical and aim at > > demonstrating a) use of Xen and b) a matu

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-10 Thread Ian Jackson
Bastian Blank writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > On Thu, Oct 09, 2014 at 12:06:23AM +0100, Ian Jackson wrote: > > The -discuss list is moderated by the Xen Project Security Team. > > Announcements of private avail

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-10 Thread Ian Jackson
Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > On this point in particular, back in 2012 [1] I suggested that all > membership requests should be discussed in public on a community email > list like xen-devel, or another

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-10 Thread Ian Jackson
Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > I also was wondering whether it would make sense to put a time-limit > on applications. For example, we could say that processing an > application will take 2 weeks. By doing so,

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-10 Thread Ian Jackson
Jan Beulich writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > There's one more thing I thought of btw: When we change the > policy following whatever community input we gathered (not just > now, but also in the future), people current

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

2014-11-10 Thread Ian Campbell
On Thu, 2014-11-06 at 16:01 +, Lars Kurth wrote: > On 5 Nov 2014, at 11:17, Ian Campbell wrote: > > > On Fri, 2014-10-31 at 15:40 -0700, Matt Wilson wrote: > >> I think that we should reduce any burden on the security team by > >> making this a community decision that is discussed in public,