> On 23 Jan 2017, at 11:30, Jan Beulich wrote:
>
>>>> On 20.01.17 at 20:21, wrote:
>> James Bulpin writes ("Re: [Xen-devel] Possible improvement to Xen Security
>> Response Process"):
>>> , and the issue is considered to be of significant
>>> On 20.01.17 at 20:21, wrote:
> James Bulpin writes ("Re: [Xen-devel] Possible improvement to Xen Security
> Response Process"):
>> , and the issue is considered to be of significant urgency due
>> to its severity, then the fourth Tuesday in the month sh
James Bulpin writes ("Re: [Xen-devel] Possible improvement to Xen Security
Response Process"):
> On Tue, 2016-12-13 at 08:42, Jan Beulich wrote:
>> On 12.12.16 at 18:11, wrote:
> >
> > Hmm - this means 6 weeks of latency in the worst case. I don't
>
On Wed, 2017-01-04 at 13:02, Jan Beulich wrote:
On 04.01.17 at 12:58, wrote:
>> On Tue, 2016-12-13 at 08:42, Jan Beulich wrote:
>> On 12.12.16 at 18:11, wrote:
I'll join in the bunfight with a stronger proposal (noting in
passing that according to https://xenbits.xen.org/xsa/
>>> On 04.01.17 at 12:58, wrote:
> On Tue, 2016-12-13 at 08:42, Jan Beulich wrote:
> On 12.12.16 at 18:11, wrote:
>>> I'll join in the bunfight with a stronger proposal (noting in passing
>>> that according to https://xenbits.xen.org/xsa/ we are now expecting 5
>>> consecutive weeks of XSA
On Tue, 2016-12-13 at 08:42, Jan Beulich wrote:
On 12.12.16 at 18:11, wrote:
>> I'll join in the bunfight with a stronger proposal (noting in passing
>> that according to https://xenbits.xen.org/xsa/ we are now expecting 5
>> consecutive weeks of XSA announcements):
>> 1) Where practical, X
>>> On 12.12.16 at 18:11, wrote:
> I'll join in the bunfight with a stronger proposal (noting in passing
> that according to https://xenbits.xen.org/xsa/ we are now expecting 5
> consecutive weeks of XSA announcements):
> 1) Where practical, XSA public disclosures will be batched and announced
> o
On Mon, Dec 12, 2016 at 9:11 AM, Matthew Allen wrote:
> On Wed, 2016-12-07 at 16:23 +, Ian Jackson wrote:
>> ...
>> I have an alternative concrete suggestion:
>>
>> Unless there are good reasons to diverge, our suggestions to
>> discoverer(s) will be based on the following criteria, in order
On Wed, 2016-12-07 at 16:23 +, Ian Jackson wrote:
> ...
> I have an alternative concrete suggestion:
>
> Unless there are good reasons to diverge, our suggestions to
> discoverer(s) will be based on the following criteria, in order of
> precedence:
> 1. Avoiding disclosure on Fridays, week
Matthew Allen writes ("Re: [Xen-devel] Possible improvement to Xen Security
Response Process"):
> I agree; I'm suggesting changes to the dates that the security team
> would propose to a discoverer.
Right.
Personally I think that batching would be valuable, if it do
On Mon, 2016-12-05 at 11:24 -0800, Stefano Stabellini wrote:
> On Mon, 5 Dec 2016, Jan Beulich wrote:
> > >>> On 05.12.16 at 15:17, wrote:
...
> > > Obviously, some issues are discussed in public before the security
> > > impact is realised (such as XSA-201); equally, the right to set
> > > a di
On Mon, 5 Dec 2016, Jan Beulich wrote:
> >>> On 05.12.16 at 15:17, wrote:
> > From a security purist point of view, any delay in publication could
> > increase the possibility of vulnerabilities being exploited in the
> > wild. However, given the significant frequency of publication of XSAs,
> >
>>> On 05.12.16 at 15:17, wrote:
> From a security purist point of view, any delay in publication could
> increase the possibility of vulnerabilities being exploited in the
> wild. However, given the significant frequency of publication of XSAs,
> I’d suggest that users failing to keep up with t
According to https://xenbits.xen.org/xsa/ we are in the middle of
4 consecutive Tuesdays of security announcements: XSA-19[1-8]
on Nov. 22, XSA-201 Nov. 29, XSA-199 Dec. 6 and XSA-200 Dec. 13.
The present security policy does not encourage batching of XSAs and
I would like us to consider refining
14 matches
Mail list logo
