[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 3 Mar 2011 18:59:20 -0500
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: oss-security@...ts.openwall.com
Cc: Greg KH <greg@...ah.com>, Kees Cook <kees@...ntu.com>
Subject: Re: Vendor-sec hosting and future of closed lists
Hi all,
>
> Then, as I have always said, someone needs to step up and actually do
> this type of communication work. I personally don't have the time to, I
> am swamped with just getting the stable updates out in a semi-timely
> fashion. Digging through every patch in these releases and properly
> conveying the real, or percieved reason why they are needed, is a lot of
> thankless work. Jon at lwn.net tried it for just one release, and we
> are averaging about one a week (total number of kernels released that
> is). No one else has yet tried to do that, but if they will, I will be
> _glad_ to point my release notifications at that summary.
>
> So in other words, help is gladly accepted :)
>
Rather than requiring individuals to perform substantial amounts of
digging through patches, which I agree is infeasible, perhaps it would
be more reasonable to establish a general policy that bug reporters
and maintainers can use to work with distro security teams and the
rest of the security community.
For example, a public or private list could be established for all
*potential* kernel security issues, and just as is the case with
CC'ing stable, a policy could be developed where maintainers are
expected to CC this list for fixes that might possibly have security
relevance, with a tendency towards erring on the safe side if security
impact is unclear. I think security communication needs to be
improved at the commit level (as opposed to the reporting), since
maintainers are often much more knowledgeable and better able to
understand security impact than the users who are often presenting
issues. Criteria could be set up for what kinds of issues would be
candidates for being sent to this list. I don't think this would
require substantially more work on anyone's part, but by creating a
culture where potential security issues are treated seriously, it
would at least stop some of the silent patching that's been going on.
Once potential security issues have been submitted to such a list, I'm
sure there would be no shortage of people willing and able to analyze
security impact for each issue, including assigning CVEs. While
digging through every kernel patch might be too much work, with the
cooperation of maintainers this can be reduced to a much smaller
subset that would be easily dealt with.
Regards,
Dan
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.
