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

[Stephen J. Turnbull]

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

    Jim> Stephen J. Turnbull wrote:

    >> 5.  Security patches are asynchronous, like earthquakes, they
    >> happen when they happen.

    Jim> Very bad analogy.  Hurricanes would be better.  There is
    Jim> plenty of potential for user-base warning before a patch is
    Jim> to be released.

Oh, if you prefer windstorms, hurricane is a bad analogy.  Far more
accurate is "tornado".<0.1 wink>

Let's look at the pragmatics.  Are you suggesting that if on Friday at
4:45, a patch is developed 72 hours faster than the estimate, the
developers should withhold the patch until the scheduled announcement
time?  Or that although the developers release the patch, site admins
should wait until the scheduled announcement time to apply it?

    >> 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?

    Jim> Change "daughter" to "wife" and ask yourself how long your
    Jim> wife would remain if you kept canceling Friday dinner at the
    Jim> last minute.

I thought about issues like that 35 years ago, when I decided to
become a professor.  This is one reason I don't regret that decision.

Now, you may be "stuck" in your position for financial reasons, or
because of the other more attractive aspects it presents, but I don't
accept that that gives you a claim on the developers' evenings and
weekends, even if users like you outnumber the developers 100:1.

    Jim> Now look at it from a business standpoint and try and
    Jim> convince my customers that they should expect their service
    Jim> to be down at any point in time to do unplanned system
    Jim> upgrades.

Um?  Redundancy, man.  Either your customers pay for reliability, or
you don't provide it.  (Well, you could take a loss by providing it
and not charging, I guess.)  In very few cases does a patch-level
upgrade to Mailman require stopping for long enough that anybody would
notice in the queue slop.

Or you can set up other systems to mitigate the vulnerabilities (or
not, if that's inconvenient), and do the security update on banker's
hours.

    >> 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

    Jim> No one is advocating that more info means more security.
    Jim> More info just means that users aren't the only ones in the
    Jim> dark.  If the hack is out and the developers are working on
    Jim> it, who is left to inform... THE USERS OF THE PRODUCT.  Why
    Jim> leave us in the dark?

Because it gives information to the enemy and is only of marginal
value to this user; I'm not speaking for anyone else, but I would be
surprised if I'm the only one who feels this way.  Producing security
fixes is done on exactly the kind of off-hours, do-it-now schedule
that we all dislike for applying the fixes, and I think it's a good
idea to delegate the decision-making to the same experts I trust to do
the work.

    >> (unless they're willing to shut down their systems from
    >> announcement that "we're worried" until a workaround or fix is
    >> available)

    Jim> That is an option that I reserve the right to make the
    Jim> decision on. Don't remove my capability to make that decision
    Jim> by hiding the info.

Excuse me, but it is the _volunteers'_ judgment that broadcasting that
information will hinder their effectiveness.  I value your (and my!)
capability to respond to such threats, but I acknowledge that I have
no choice but to delegate the matter to the responsible developers.
Neither I nor you have any *right* in the matter.  See Section 11 of
the License under which you received Mailman.

If you want that information so badly, there are several ways you can
arrange to get it: you can employ the developers, you can follow the
security bulletins religiously (and privately ask the the developers
what they're doing about it and privately tell those you trust about
it), you can become a trusted developer.

TANSTAAFL.

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

    Jim> I don't believe that one bit, certainly not in the scenario
    Jim> that I described.

I really have to disapprove of the way you consistently deprecate
costs that others incur, while inflating those that you face.


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