On Thu, 16 Dec 2004 19:50:19 -0600 (CST) Winship <[log in to unmask]> said:
>With this proposed new scheme, editor trumping review, rather than
>review trumping editor, as it has always been in the past, will, it
>seems
>to me, make hash of this setup, which many lists use:
>
>* Send= Editor
>* Editor= id@address,(LISTNAME)
>* Default-Options= REVIEW
>
>This is used so that postings from new subscribers will be vetted by the
>listowner (or editor if different).
This configuration, which I call The Kludge, is one of the biggest
mistakes I made in LISTSERV's 18 year history. I had so much to do back
then, a full-time student in another city a 3-4 hours' train ride away,
that I figured this would save me time. Instead of implementing a proper
feature to do what people wanted to do, I allowed this kludge to prosper.
This unfortunate decision has cost me hundreds and hundreds of hours of
time, and thousands for my colleagues in support.
The Editor privilege is the third most powerful privilege you can grant
in LISTSERV, after list owner and LISTSERV administrator. You are making
this enormous grant of rights to your entire constituency. To make this
situation viable, you need additional locks and bolts. Every time a lock
is changed in LISTSERV, there needs to be a careful review of every
possible variant of The Kludge to make sure that security is not
compromised.
The original purpose of The Kludge was to make LISTSERV forward postings
from non-subscribers to a human for review, instead of rejecting them. It
worked reasonably well at a time when LISTSERV was so much smaller and
only had a small number of security controls. Later, I added features
like the REVIEW option to do what The Kludge originally did. But this did
not kill The Kludge - people discovered new ways in which to combine
these new features with The Kludge to achieve even more subtle behaviour.
Although none of these subtle boundary combinations are guaranteed to
keep working with new releases, people expect this to be the case anyway.
Every time I change something in LISTSERV's posting control, which I
avoid like the plague, I end up breaking one or more of the subtle Kludge
combinations, and the complaints start coming. Sometimes The Kludge can
be repaired, sometimes it can't.
Much as I want long-time customers to be happy, the fact is that the
total worldwide number of Kludgemasters is somewhere between 50 and 100.
There are more people using the basic form of The Kludge because they
read it on the net somewhere or copied it from another list, but that one
is easy enough to keep alive. The true Kludgemasters are vocal, but few.
And yet most feature requests that could impact The Kludge are rejected
or delayed until there is a compelling need to change the posting control
code, as was the case in 14.3 for the "Confirm,Non-Member" option that
gets rid of spam so effectively that I cannot imagine running an open
list without that option any more.
But let's get back to your list header sample:
>* Send= Editor
>* Editor= id@address,(LISTNAME)
>* Default-Options= REVIEW
>
>This is used so that postings from new subscribers will be vetted by the
>listowner (or editor if different).
You don't need "Send= Editor" for that. You can have "Send= Private" and
"Editor= human@address". Existing subscribers can post directly unless
they have the REVIEW option, in which case they go to the editor. New
subscribers get the REVIEW option. There is no Editor vs REVIEW conflict,
and you are not granting any privileges to your entire list.
A lot of people use The Kludge out of old habit, when there are better
and *supported* ways to achieve the same thing. There is no risk that a
design change will cause REVIEW to stop working altogether in the normal
case of a "Send= Private" list (a bug could do that, but it would get
fixed of course). But the order in which the many security controls are
examined can change from one version to another, either by accident or
for a reason. If you craft a list configuration that says that X is
allowed to do something, and that at the same time says that X is not
allowed to do it, you are basically tossing a coin. The coin might always
fall on the same side for a given version of LISTSERV, but it could flip
around when the code is updated.
>Why the sudden about face, in violation of precedent? Why, previously,
>did you think that it was proper for review to override editor, but now
>you think editor should trump review?
The answer is simply that I never thought that it was proper for REVIEW
to take precedence. When the REVIEW option was added, I did not think of
the potential conflict with Editor, and the implementation happened to
give REVIEW the upper hand. Unfortunately, this implementation was unable
to support the double confirmation process of "Send=
Editor,Confirm,Non-Member" and some of the other changes I wanted to make
for 14.3. To ensure security with the double confirmation process (which
is actually a triple confirmation internally, but for any given
configuration, you will only ever see at most two of the three
confirmations), I had to change the logic substantially, and the
precedence is no longer as before. I think the new precedence makes more
sense, and I also think it is a good thing if people who do not need to
use The Kludge stop using it, not because The Kludge takes up so much
valuable development time, but because, in spite of my best efforts, I
have broken The Kludge several times in LISTSERV's history, so far
without compromising security, but one day I might make a mistake and
open up a security flaw for lists configured to use The Kludge. It is
simply safer and more trouble-free to use supported methods to achieve
the desired policy. And it is a one-time change, do it now and you won't
have to worry about precedence of list header controls again. New
customers typically don't use The Kludge because there is almost always a
way to do the same thing using supported methods and, being new
customers, they weren't list owners in 1987 when The Kludge was invented.
Eric
|
