Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 3 Mar 2011 13:36:40 -0800
From: Kees Cook <>
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 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.