[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 3 Mar 2011 13:36:40 -0800
From: Kees Cook <kees@...ntu.com>
To: oss-security@...ts.openwall.com
Subject: Re: Vendor-sec hosting and future of closed lists
On Thu, Mar 03, 2011 at 06:31:08PM +0000, Mark J Cox wrote:
> We monitor how we first found out about every issue we eventually
> fix, and if we found out before or after the issue was public.
>
> For vendor-sec, during last calendar years
>
> date # issues in advance # issues already public
> 2008 69 32
> 2009 57 17
> 2010 29 22
>
> That 29 represents just 4% of the total number of our
> vulnerabilities fixed in 2010. The median time of embargo for those
> 29 issues was 15 days (average 24)
This certainly underscores that very few flaws need vendor-sec
coordination, but I would suspect that out of those roughly 725 flaws,
many of the really critical ones came through vendor-sec. Does that match
your records? (Ubuntu doesn't currently track the origin of flaws beyond
giving credit, so I'm curious if RH's data matches my sense of critical
flaw origin.)
I'm also curious what "issues already public but found out about it on
vendor-sec" means? Does that mean it was inappropriately brought to
vendor-sec after it was already public, or that RH found out about it
after it was public even though it had already been discussed privately
on vendor-sec?
> But I think that trend is what was expected, as upstream projects
> communicate with affected vendors directly, and we use oss-security
> for issues that don't need embargo or co-ordination.
Several upstreams, though disappointingly not the Linux kernel, are very
good about keeping their end-users in mind and providing direct distro
coordination for important security updates (MIT Kerberos comes to mind
first as a great example). This number of upstreams has been growing,
but it's not nearly large enough to supplant a vendor-sec-like mailing
list, IMO.
I'm all for the public disclosure of things that are low priority. But I
think it's important to maintain coordination for really nasty flaws,
otherwise we're in a position to really do a disservice to end-users.
-Kees
--
Kees Cook
Ubuntu Security Team
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
