[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Possible improvement to Xen Security Response Process

On Mon, Dec 12, 2016 at 9:11 AM, Matthew Allen <matthew.allen@xxxxxxxxxx> wrote:
> On Wed, 2016-12-07 at 16:23 +0000, 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, weekends, or on or immediately
>>     before widely respected public holidays.
>>  2. Minimising the number of distinct publication dates
>>     within each 14 day period.
>>  3. Making the preparation period for each advisory as close,
>>     on a log scale, to 14 days as possible.
>>  (The preparation period for an advisory is the period between
>>  predisclosure and publication.)
>> ...
>> Bunfight, anyone ?
>> Ian.
>> (Responding with a personal opinion, and hence from a personal
>>  email address.  I haven't discussed this with my management at
>>  Citrix.)
> 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
> once per month.
> 2) The calendar of disclosure dates will be published well in advance
> and will avoid Fridays, weekends, or dates on or immediately before
> widely respected public holidays.
> 3) Issues will normally have at least 14 days pre-disclosure; this means
> that an issue discovered immediately prior to a scheduled publication
> date will normally not be disclosed until the next publication date.
> Clearly there will be times when this can't be done; I am also aware
> that discoverers always have the final say.  But both of those points
> apply to the current policy as well.
> I know that this would be a significant change.  However, the present
> frequent and unpredictable nature of disclosures consumes a lot of time
> that would otherwise be better spent on contributing to and improving
> Xen.

I think this assumes that the response is to apply all patches, test
as one unit, and then make available.

OTOH, if you are doing a detailed assessment of each issue,
determining scope of impact, creating regression tests, etc then
batching means that there is a lot more work to fit in a smaller time


Anthony Liguori

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.