[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 28 Apr 2011 08:24:51 -0400
From: "Mike O'Connor" <mjo@...o.mi.org>
To: oss-security@...ts.openwall.com
Subject: Re: Closed list
:Two eyes = one mouth (mostly), so yes, there were certainly fewer leaks
There are other relevant orifices.
:linearly with respect to the number of participants. So the problem is
:simply limiting the number of participants to the absolute minimum
:necessary. The only way to do that (I think) is to empower the
:researcher to make the call for him/herself based on what they know
:about their issue. Of course, participants in follow-on discussion can
:to expand participation to others if they are affected by the issue at
:hand.
Researchers can already make that call. We've seen outcomes of that
before. Sometimes, it's easy to isolate a problem to a given distro.
Sometimes, it's a lot less obvious, and some vendors are left out in
the cold who really shouldn't have been. I wouldn't necessarily rely
on _explicit_ cooperation amongst individual distros to do that sort
of message passing, especially when they may be competitors in some
sense or other.
:> The issue there is that some folks don't necessarily have a good
:> handle on the issue where they _can_ reasonably target things. The
:> same has sometimes been true even for the coordinating bodies who one
:> might think would know better. Often, it's the vendor/distro reps who
:> know the particular nuances of their present and future product better
:> than anyone else. For a sufficiently diverse product base, that kind
:> of knowledge is not easy to break down into some checklist ready-made
:> for narrow targeting of issues.
:
:That would be easy enough to solve. Provide key lists for important
:groups (an "open" linux distro key list, an "open+closed" linux provider
:key list, an all unix-like os key list, etc.) and pre-cooked one-liners
:to encrypt for those sets, then let the researcher choose which one they
:want.
Some CERTs already operate roughly in this kind of way. This isn't
a new idea. It's not clear that it's been especially effective, based
on "what I've gotten that I probably shouldn't have gotten" + "what
I've missed that others have gotten".
:> Make the barrier for participation high enough for the discoverer of
:> an issue (who may not always be a "researcher" in any classic sense)
:> and the level of participation will be correspondingly low. Keep in
:> mind that for many of the open source communities that vendor-sec has
:> interacted with, security is _not_ their primary focus. Most people
:> write code so they can actually get stuff done. :)
:
:If documentation is sufficient and pre-cooked commands readily
:available, this shouldn't be a problem. People can (and should) be
:able to learn. Typing "gpg --encrypt --recipient <key 1> --recipient <key 2>"
:isn't all that difficult.
Any major "procedure" for reporting a security issue will mean that
it's less likely to get reported. The "researcher" (who may be some
sysadmin who found a seemingly-novel exploit script on their cracked
system) who's going to wade through a bunch of assorted email addresses
to cherrypick the right place(s) to send an issue is just as likely
to pick a few major distros and call it a day.
Imagine if oss-security were broken up into a bunch of different
sub-lists, like you describe. How effective would it be?
:> enough like-minded folks decide they need to handle the core of the
:> issues reported on the list off-list. At that point, the list
:> archives might turn into some kind of kabuki dance. To that end, it
:> helps to have a bunch of folks on the list who _aren't always_ quite
:> so like minded.
:
:The important consequence is that the outside world will be empowered to
:see the inner workings of the one unfortunately closed part of an
:otherwise completely open system.
It's not a "completely open" system. There's many open-source
components whose security arms continue to operate in relative secrecy
while developing the fix to an issue. Some don't necessarily share
such info very well -- not necessarily out of malice, but sometimes
because it just doesn't occur to them (a bug is a bug!). vendor-sec
was a mechanism to consolidate _some_ of that, nothing more or less.
oss-security has been another helpful means (and again, thank you
Solar for setting this up :) ).
--
Michael J. O'Connor mjo@...o.mi.org
=--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"Save regularly in our bank. You'll never reget it." -a classified ad
Content of type "application/pgp-signature" skipped
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.
