archive2.pl 1.10:1.9
revision 1.10
date: 1997/08/27 15:07:44; author: cwilson; state: Exp; lines: +22 -7
From:
[email protected] (Rodent of Unusual Size)
Message-id: <
[email protected]>
o capability for 4 digit years
However, just in case it's not, here's a patch to archive2.pl that
adds -D, -M, and -Y flags that have the same meanings as their
lower-case counterparts - except that the year is 4 digits rather
than 2.
----------------------------
config-test 1.18:1.17
revision 1.18
date: 1997/08/27 15:17:13; author: cwilson; state: Exp; lines: +3 -3
o Checks to make sure that $log is actually a file.
----------------------------
config_parse.pl 1.64:1.63
revision 1.64
date: 1997/08/27 14:41:32; author: cwilson; state: Exp; lines: +17 -1
[
ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/config_majordomo.0 ]
From: Bill Houle <
[email protected]>
Message-Id: <
[email protected]>
The following patches implement the 'welcome=yes/no' and
'announcements=yes/no' keywords for Majordomo 1.94.3. Both features have
been requested several times on the -users mailing list. In the past I had
described how our site implemented these for 1.93 using the new_keyword()
API function call, but since I am in the process of upgrading I figured I'd
do it this time as a real patch. I submit them for local implementation and
hopeful incorporation into 1.94.4. (Yes, I know these are new features
which are not typical for inclusion in a point release. But heck, they are
so simple its laughable...)
----------------------------
digest 1.23:1.22
revision 1.23
date: 1997/08/27 14:42:52; author: cwilson; state: Exp; lines: +30 -13
[
ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/digest.0 ]
From: Dave Wolfe <
[email protected]>
Message-Id: <
[email protected]>
These patches fix some problems recently identified in digest, but are
virtually untested. They address undefined variables when the non-C form
of configuration is used and file globbing failures (i.e. "No messages"
aborts when there are plenty of messages to digest). While I have the
highest confidence in the changes, unless someone can verify them I
can't that they be placed in the release. They should be tested
*both* with and without using the -C option.
----------------------------
majordomo 1.88:1.87
revision 1.88
date: 1997/08/27 14:55:29; author: cwilson; state: Exp; lines: +21 -41
[
ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/majordomo.0 ]
[
ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/majordomo.1 ]
[
ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/majordomo.2 ]
From: Dave Wolfe <
[email protected]>
Message-Id: <
[email protected]>
o Race condition:
The problem is a window when Mj is unsubscribing an address between the
time the list file is unlinked and the updated file is linked to the
list file name.
From: Dave Wolfe <
[email protected]>
Message-Id: <
[email protected]>
o Config lock not being freed:
I discovered a case when a config lock isn't freed when newconfig fails
due to errors in the settings then a following (in the same message)
config or writeconfig command fails because set_lock() is called again
without the lock ever being freed. I suppose I could make set_lock()
less picky, but the problem is actually bad logic in do_newconfig(), so
I'd rather fix that. Here's the patch against 1.94.3:
From: Dave Wolfe <
[email protected]>
Message-Id: <
[email protected]>
o EOF tests failing due to intervening filehandle resets.
Since I use my lockf() version of shlock.pl, I discovered that the tests
for eof on the command input stream in do_newinfo() and do_newintro()
make a rather tenuous assumption in at least one case for each function
because there's an intervening log() call (and resulting file locking)
between the last input from the command stream and the eof test on the
last filehandle read.
----------------------------
majordomo.pl 1.56:1.55
revision 1.56
date: 1997/08/27 14:58:53; author: cwilson; state: Exp; lines: +10 -10
[
ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/majordomo.pl.0 ]
From: Dave Wolfe <
[email protected]>
Message-Id: <
[email protected]>
o Mungedomain doesn't work due to is_list_member() bug
> > The problem I am having is that mungedomain seems not to work
> > when the subscribed person is
[email protected] and the From: line in the
> > mail is
[email protected]. [ on 1.94.3 ]
>
> You have also found a bug. It's even worse if you list a file other than
> the list in 'restrict_post'. I'm working on it but since I'm out this
> afternoon and have a training class the next 2 days, it may be awhile
> before I have a patch for it.
>
> For those who care, is_list_member() in majordomo.pl clobbers
> $clean_list before it uses it to call cf_ck_bool() to get the value
> of 'mungedomain'. Then there's the problem of it not making sure that
> get_config() has been called for $clean_list, not to mention that resend
> calls is_list_member() with the value of 'restrict_post' that might not
> even be a list at all!
Turns out this wasn't as tricky as I feared once I made the assumption
that only the "current list" 'mungedomain' applied. Here's patches
against 1.94.3:
----------------------------
resend 1.86:1.85
revision 1.86
date: 1997/08/27 14:59:24; author: cwilson; state: Exp; lines: +4 -8
[
ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/majordomo.pl.0 ]
From: Dave Wolfe <
[email protected]>
Message-Id: <
[email protected]>
o Mungedomain doesn't work due to is_list_member() bug
> > The problem I am having is that mungedomain seems not to work
> > when the subscribed person is
[email protected] and the From: line in the
> > mail is
[email protected]. [ on 1.94.3 ]
>
> You have also found a bug. It's even worse if you list a file other than
> the list in 'restrict_post'. I'm working on it but since I'm out this
> afternoon and have a training class the next 2 days, it may be awhile
> before I have a patch for it.
>
> For those who care, is_list_member() in majordomo.pl clobbers
> $clean_list before it uses it to call cf_ck_bool() to get the value
> of 'mungedomain'. Then there's the problem of it not making sure that
> get_config() has been called for $clean_list, not to mention that resend
> calls is_list_member() with the value of 'restrict_post' that might not
> even be a list at all!
Turns out this wasn't as tricky as I feared once I made the assumption
that only the "current list" 'mungedomain' applied. Here's patches
against 1.94.3:
----------------------------
sample.cf 1.34:1.33
revision 1.34
date: 1997/08/27 15:00:31; author: cwilson; state: Exp; lines: +3 -3
[
ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/sample.cf.0 ]
[
ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/sample.cf.1 ]
o Uncommented $config'default_subscribe_policy
o made the sample taboo stuff valid perl5.
----------------------------
wrapper.c 1.8:1.7
revision 1.8
date: 1997/08/27 15:01:12; author: cwilson; state: Exp; lines: +6 -4
o Fixes security hole with ENV overrun by limiting env size.
----------------------------
