Date: Thu, 3 Mar 2011 13:23:21 -0800 From: Kees Cook <kees@...ntu.com> To: oss-security@...ts.openwall.com Subject: Re: Vendor-sec hosting and future of closed lists Hi, On Thu, Mar 03, 2011 at 07:12:24PM +0100, Marcus Meissner wrote: > So I would like to open up a discussion with _all_ OSS Security folks present. > > - Is a closed vendor coordination like vendor-sec still needed at this time? > > Meaning: does the benefit of a closed group really outweigh the > "left out feeling" of non members and its annoyances? I believe the utility of a closed "vendor coordination" mailing list is related to the criticality and time-frame of certain flaws. The goal of such private coordination is to protect end-users, who are generally running a stable release of various packaged pieces of software and are not in a position to always use the bleeding-edge. Instead of making it a race to see which distro can protect their users faster at the cost of making other distro's users vulnerable, private coordination has been used to make sure all users of all distros are fixed (or at least have the packaged fix available) at the same time. I think this approach still has value, but with some caveats. Having a single place for vendors to coordinate a fix for critical flaws seems like a good idea as long as that time-frame is short. The overhead of coordination only has value if the flaw is serious. The risk of leak or independent public discovery goes up the longer a fix takes. Therefore, fixes must be handled quickly. On the flip side, while it seems like sitting on minor issues isn't a problem, since their criticality is low so the risk of leak is lower, it actually is a problem because it does a disservice to upstreams (and end-users) that may not know about the issue yet. (If no one in the private group is acting on the issue, it should be made public so more people can see it or work on it.) Ubuntu's stance on privately reported/discovered flaws has been to choose a roughly 1 week Coordinated Release Date, email the details to vendor-sec (and upstream's private email when we can find one). If no one responds, the CRD expires, and we make the flaw public. So far, this seems to naturally select the high criticality flaws for quick coordination and fixing and the less critical issues for becoming public quickly. For public issues, we've tried to have them raised on oss-security@ or with upstreams directly. > - If yes, would it be an idea to confine or split into lists of focus groups? > (like Linux vendors, BSD vendors, all OSS source using vendors, etc?) It seems to me that if you're releasing stable package updates for some portion of the Free Software stack, you should be in the short-CRD private disclosure fix-coordination mailing list. > - Or of course the old option is open: > Should we proceed with the current state as-is, but throw a bit more > GPG encryption on top? Encryption would reduce the scope of potential leaks, but not eliminate it. It's not clear to me if the overhead is worth the change in leak risk. Now, culturally, this has all been about reactive security. It sure would be nice to have more cultural movement toward proactive security, especially for the Linux kernel. I don't think a mailing list will fix that, but I thought I'd bring it up anyway. Proactive security should be just as valuable as reactive security... -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.