Re: Closed list

["Mike O'Connor" <mjo () dojo mi org>]

: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 () dojo mi org
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"Save regularly in our bank.  You'll never reget it."        -a classified ad

Attachment: _bin
Description: