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

[Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx>]

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 does not
lead to either inordinate delay or precipitate publication.  Of course
opinions about what "inordinate" or "precipitate" mean are likely to
produce some disagreements...

Matthew's suggestion of having fixed dates is a possible way forward
but it might also lead to avoidable delays.


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.)

Essentially this means that if predisclosure of a second batch occurs
in the first 5 days of a 14 day preparation period, the existing date
will be reused; on or after the 6th day, a new date, beyond, will be
suggested.  So the minimum preparation period is 9 days (9/14 = ie,
1.55x too short), and the maximum is 22 days (22/14 = 1.57x too long).
(Figures slightly fudged due to day-granuarity rounding error.)

That's a suggested compromise between those who will want to do
batching by making the timescales shorter and those who want to make
them longer.  (Using a log scale avoids the problem that a linear
scale would mean that the error factor would be ~2x short but only ~1.5x
long.)


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.)

-- 
Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel