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
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
>>> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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,
20 matches
Mail list logo
