Home page logo
/

oss-sec logo oss-sec mailing list archives

Re: distros & linux-distros embargo period and message format
From: Marc Deslauriers <marc.deslauriers () canonical com>
Date: Wed, 01 Feb 2012 19:29:05 -0500

On Thu, 2012-02-02 at 03:54 +0400, Solar Designer wrote:
Marc,

Thank you for your feedback.

On Wed, Feb 01, 2012 at 04:02:54PM -0500, Marc Deslauriers wrote:
A week is a pretty short delay to prepare updates and perform the
necessary QA to get an issue out on time. Why are you pushing to get the
maximum reduced?

Why shorter embargo periods are preferable: vendors who are ready to
push out their updates first don't have to sit on those updates waiting
for others, users get their fixes sooner, the potential for leaks (or
rediscovery) and exploit development in the wild before a fix is out is
reduced, the potential for a vendor inadvertently releasing before the
CRD is reduced (and in case this happens anyway, other vendors are
likely "more ready" by that time since they knew the CRD was sooner),
fewer embargoed issues are being tracked at the same time (less work,
lower risk of errors).

This means vendors will be keeping information about the vulnerability
private until they are confident they are able to release within a week,
at which point they will then share the information with other vendors
who will scramble to get their updates ready.

As a distro, I now have two choices: I sit on vulnerabilities until our
own QA and testing is done, at which point I send them to the list and
hope that 7 days is enough for everyone else, or I simply stop using the
list for anything that's more than trivial and contact other vendors
directly.

Why 7-11 days: a few issues were recently handled within 7 days fine -
such as the sudo issue (easy fix provided by upstream and not needing
much QA) and the Linux kernel /proc/<pid>/mem issue (vendors had to
hurry up because the issue was mostly public).

Yes, those are two excellent examples of basically one line fixes where
a week was sufficient to publish updates. I don't think they should be
used as a reference to determine what an acceptable delay is.

  So this may be realistic
at least as a target (hence my wiki page edit) or maybe also as the
maximum (hence my proposal).  Additionally, the original maximum of 14
days may be seen as potentially including the extra days needed based
on day-of-week: it is one week normal + some days from the other week
when needed by day-of-week.  So maybe me trying to meet the reality
(seen on a few occasions) by extending this to 14-19 days was wrong, and
I instead should have proposed 7-11 days.  Hence the belated proposal.

For us, 7-11 is too short for certain complexe issues. 14-19 is a
reasonable delay to backport patches, perform adequate QA and publish.


Why me: I feel that it's my duty as list admin to propose the smallest
maximum embargo period that list members might be willing and able to use.

Why I am making this proposal now: this is triggered by a certain
off-list discussion I just had; unfortunately, the other party does not
permit me to post more about it.  However, as I wrote above, I feel that
I have good reasons to give this proposal a try (see if it's acceptable
or not) regardless of what triggered these thoughts now.

Reducing the maximum will just result in having everyone miss the
embargo date and putting users at risk.

It's not that simple.

Not "everyone" will miss the CRD.  Clearly, if some vendors on the list
are comfortable with a shorter embargo they either expect to meet the
CRD or find the issues for which they miss the CRD not important enough
to fix before CRD anyway.

Or, they have waited until they were ready before telling everyone else
about it simply to adhere to the new list rules.

I already provided some answers to "why" above, and here's one more: the
change may also result in vendors' processes being adjusted to meet the
faster pace.  I am unsure to which extent this is positive overall,
though (considering that those changes may have side-effects).

This will result in issues becoming public before everyone's updates are
ready to be published, nothing more.

Marc.





  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]