Re: Closed list

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

:I know that there is increasing momentum for the new setup, but I
:think this solution is wrong.  Its starting to look a lot like the old
:vendor-sec (too many participants), and drawing an appropriate line for

How many participants are on security () kernel org?  How many are part
of the Mozilla security team?  (And yeah, I know the answer there --
http://www.mozilla.org/projects/security/secgrouplist.html).  There's
an assumption that "more = worse", but how many is really too many?
You only get the answer when it seems to stop working.  

:participation is impossible and seems wrong.
:
:The ideal solution to the "too many eyes" problem would be to empower

The problem with vendor-sec of old seemingly wasn't so much "too many
eyes" -- more like "too many mouths", too many points of leakage.  It
wasn't at all clear how much of the vendor-sec leaks were due to any
one list member in particular (because there were many exploders), bad
infrastructure, a combination of factors, etc.  Apart from that, it
seemed to be _mostly_ working, which may be as well as could ever be
expected in reality.

:the researcher (issue submitter) to choose exactly which eyes they want
:involved.  A way to achieve this would be a ml that accepts only

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.  

:encrypted messages for participants (participation would be unlimited)
:and an "archive participant".  The list of participants is open to all
:(for the purpose of the researcher seeing which keys they want to
:encrypt for).
:
:When sending a message to the list, the researcher has to encrypt the

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.  :)

:message for archive key and at least one other valid participant (if
:not the message should be rejected, and instructions sent with a list of
:valid participant key fingerprints). In order to make sure the message
:was validly received, a checksum of the message should be published to
:an open list (probably oss-sec).  The researcher can check this right
:away.
:
:Finally, the cleartext message should be posted to an open list after a
:period of time (probably two months max) so that the entire community
:can see and validate the closed discussion .  This eliminates the
:possibility of a secret cabal forming or at least empowers the outside
:world to see the true reality (although with a delay).

It doesn't _eliminate_ the possibility of any sort of cabal forming.
It's simply a gesture of good faith, which could be subverted if
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.


-- 
 Michael J. O'Connor                                          mjo () dojo mi org
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"Follow that allergy!"                                              -The Tick

Attachment: _bin
Description: