[Mailman-Users] any info on this reported exploit?

[Stephen J. Turnbull]

>>>>> "Jim" == Jim Popovitch <jimpop at yahoo.com> writes:

    Jim> I guess we just see system administration from different
    Jim> angles, I prefer communication to silence.

Of course.  So does everybody.  Specifically, so do the crackers.

    Jim> Barry/Tokio/Mark: Folks, yesterday we were informed of a
    Jim> serious (i.e. potential for data loss) issue with MM 2.1.5+.

That's cheating, man.  A "potential for data loss" issue, as long as
it's possible to trigger in normal operation, gets announced
immediately.  What we're talking about here is a hostile agency that
is specifically out to get you, and is quite possibly listening to
your broadcasts.

    Jim> Somebody please tell me what is wrong with that level of
    Jim> communication on vulnerability/security issues.

1.  The scenario you describe is basically the process that will
happen according to the discussions that led up to the security FAQ.
In other words, mostly you've already got what you're asking for.

2.  Except for the initial broadcast that announces that there is now
a race between the hackers and the crackers, and how long the crackers
have to exploit the hole.  Whether you believe that is a reasonable
interpretation or not, many developers do, and they will respond to
such a leak by working harder on the problem, at the cost of their own
weekends, etc.  This did happen the last time there was a security
"announcement" by a third party on Mailman-Users; that's what prompted
the posting of the security FAQ.

3.  AFAIK none of the Mailman developers get paid for what they do.
How about *their* weekends and their regular jobs?

4.  Writing such memos is a non-trivial amount of effort.  And weekend
or not, I'm sure he'd rather be spending the time working on the fix.

5.  Security patches are asynchronous, like earthquakes, they happen
when they happen.  If the patch comes out on Friday at 4:45, I would
cancel that dinner date with my daughter.  Wouldn't you?  What
difference would notice on Tuesday that a patch is expected sometime
on Friday make to that decision, anyway?

In sum, I just don't see what benefit there is to the process you
outline relative to current policy.  The information doesn't make
anyone more secure (unless they're willing to shut down their systems
from announcement that "we're worried" until a workaround or fix is
available), communication with users will slow production of the fix
but won't reduce the variance on when it gets released, and it's a
non-negligible burden on the developers.


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.