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

[Jim Popovitch]

Stephen J. Turnbull wrote:
>>>>>> "Jim" == Jim Popovitch <jimpop at yahoo.com> writes:
> 
> Oh, if you prefer windstorms, hurricane is a bad analogy.  Far more
> accurate is "tornado".<0.1 wink>

Hurricane is the most accurate analogy, because with hurricanes nobody 
knows about them until the NWS (at least here in the USA) informs them 
or they hear about it in the Media.  Even then, most people don't fully 
know the specifics of the hurricane, nor do they necessarily posses the 
skills to understand the dynamics of the hurricane.  HOWEVER, with 
sufficient info from the NWS people can prepare to address the 
inevitable effects of the hurricane should the need arise.

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

No.  What I am suggesting/recommending is this:  If the developers know 
on Monday of some super secret issue, and presumably they won't have a 
robust fully-tested solution until Friday, I want them to tell me in 
no-detail to alert me to be prepared for a Friday emergency patch.  How 
is that risky?

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

You mis-characterize (yet again?) what I am saying. I am not advocating 
for the developers to work more, or differently.  I am only asking for a 
"heads up", not a last minute announcement.  I don't want to be one of 
the last people to know of ANY Mailman security issue.  As a user of 
Mailman I expect to be kept in the loop by the vendor.  Microsoft gives 
more patch/release "heads up" info then Mailman does, think about that 
for a while.

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

My thoughts exactly.  I trust them to do the work and produce a fix. 
Again, all I am advocating is that if they are spending 6 days on a fix, 
don't wait until the 7th day to fill us in.  Let us know up front that 
they are working a possible fix that may need to be applied.  Where's 
the harm in that?

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

Huh?  re-read my comments.  I reserve the right to shut my Mailman 
system down, for any reason, at any time, lack-of-a-workaround or not.

> If you want that information so badly, there are several ways you can
> arrange to get it: 

Again, you mis-understand my interests.  I don't want info on the hack, 
I want a "heads-up" that <unidentified> fix is in the pipe and sysadmins 
can expect it late Friday (or whenever).  Again, how is that so egregious?

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

Why should Mark/Barry/Tokio trust me anymore then the next guy? 
Honestly, I expect them NOT to.  There is nothing I am asking for that 
needs to involve trust, or disclosure concerns.

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

You need to re-read what I've been writing.

-Jim P.