Mailman 3 April 2002 - Mailman-Developers

Re: [Mailman-Developers] japanesecodes-1.4.5 install prob
by Ron Jarrell 27 Apr '02

27 Apr '02

At 05:51 AM 4/27/02 +0900, Tamito KAJIYAMA wrote: >I got reports that bdist_wininst and bdist_rpm posed similar >problems. Attached below are the patches the reporters sent >to me. Honestly speaking I cannot figure out a right way that >fixes problems on all platforms with any distutils options. > >Any comments and suggestions are very appreciated. > >Regards, > >-- >KAJIYAMA, Tamito <kajiyama(a)grad.sccs.chukyo-u.ac.jp> > > >For bdist_wininst: >--- setup.py.orig Thu Apr 18 01:20:38 2002 >+++ setup.py Thu Apr 18 01:20:16 2002 >@@ -27,7 +27,7 @@ > def finalize_options (self): > install.finalize_options(self) > self.distribution.data_files = [ >- (self.install_purelib, ["japanese.pth"])] >+ ("lib/site-packages", ["japanese.pth"])] > > setup (name = "JapaneseCodecs", > version = "1.4.5", > > >For bdist_rpm: >--- setup.py.orig Wed Apr 17 16:42:13 2002 >+++ setup.py Thu Apr 18 19:50:49 2002 >@@ -2,6 +2,7 @@ > # Tamito KAJIYAMA <30 November 2000> > # $Id: setup.py,v 1.7 2002/04/17 03:53:31 kajiyama Exp $ > >+import sys, os > from distutils.core import setup, Extension > from distutils.command.build_py import build_py > from distutils.command.install import install >@@ -27,7 +28,8 @@ > def finalize_options (self): > install.finalize_options(self) > self.distribution.data_files = [ >- (self.install_purelib, ["japanese.pth"])] >+ (os.path.join(sys.prefix, 'lib', 'python'+sys.version[:3], >'site-packages'), >+ ["japanese.pth"])] > > setup (name = "JapaneseCodecs", > version = "1.4.5", Uhh, I would think this would make the problem worse. These patches would *force* the .pth file into the system site-packages directory, even if the user has specified install options to force them into a private directory. In this case mailman's install is trying to install the codecs into a private library that mailman uses. mailman's install is specifically designed so as to *not* be installed as root, which makes it generally impossible for it to install the codecs if they *have* to go into site-packages...

2 1

Is MM cookie auth 'secure' thru HTTP proxy servers?
by Richard Barrett 27 Apr '02

27 Apr '02

Can someone out there sanity check my thinking on a possible hole in Mailman's cookie based authentication. The scenario I'm concerned with is when Mailman's web GUI is being accessed by a browser via a caching HTTP proxy server such as Squid, hardly an uncommon situation these days. If my understanding is correct, then Squid (legitimately and like probably any other HTTP proxy) has no qualms about caching a page merely because of the existence of Cookies or Set-Cookie headers in the response or request. This is justified by RFC 2616. The Squid FAQ says: <quote> The presence of Cookies headers in requests does not affect whether or not an HTTP reply can be cached. Similarly, the presence of Set-Cookie headers in replies does not affect whether the reply can be cached. </quote> It appears to me that in the absence of a Cache-Control header with a value of private, no-cache or no-store a caching proxy server is free to cache the response to an HTTP request purportedly protected by MM's cookie based authentication AND to again serve that response to any other requesting client WITHOUT consulting the server delivering the Mailman web GUI. I am hoping one of you kind readers will tell me I have missed the obvious in my examination of the problem and the MM source, or that the scenario above is invalid for any reason. In the meantime I'm working up a patch to block this possible security hole by adding Cache-Control headers in the HHTP responses generated by MM's web GUI.

2 1

Re: Is MM cookie auth 'secure' thru HTTP proxy servers?
by Richard Barrett 27 Apr '02

27 Apr '02

Further to what I said before (see below), I now enclose a patch to correct the problem. The patch is to the WebAuthenticate function in Mailman.SecurityManager. It adopts the simple hypothesis that if you are setting or checking a cookie then the response about to be made shouldn't be cached. >Date: Mon, 22 Apr 2002 17:30:14 +0100 >To: mailman-developers(a)python.org >From: Richard Barrett <r.barrett(a)ftel.co.uk> >Subject: Is MM cookie auth 'secure' thru HTTP proxy servers? > >Can someone out there sanity check my thinking on a possible hole in >Mailman's cookie based authentication. > >The scenario I'm concerned with is when Mailman's web GUI is being >accessed by a browser via a caching HTTP proxy server such as Squid, >hardly an uncommon situation these days. > >If my understanding is correct, then Squid (legitimately and like probably >any other HTTP proxy) has no qualms about caching a page merely because of >the existence of Cookies or Set-Cookie headers in the response or request. >This is justified by RFC 2616. The Squid FAQ says: > ><quote> >The presence of Cookies headers in requests does not affect whether or not >an HTTP reply can be cached. Similarly, the presence of Set-Cookie headers >in replies does not affect whether the reply can be cached. ></quote> > >It appears to me that in the absence of a Cache-Control header with a >value of private, no-cache or no-store a caching proxy server is free to >cache the response to an HTTP request purportedly protected by MM's cookie >based authentication AND to again serve that response to any other >requesting client WITHOUT consulting the server delivering the Mailman web GUI. > >I am hoping one of you kind readers will tell me I have missed the obvious >in my examination of the problem and the MM source, or that the scenario >above is invalid for any reason. > >In the meantime I'm working up a patch to block this possible security >hole by adding Cache-Control headers in the HHTP responses generated by >MM's web GUI. patch file: cut here -------------------------------------------------------------------------- --- mailman-2.0.10/Mailman/SecurityManager.py Tue Nov 6 04:25:26 2001 +++ mailman-2.0.10-cache/Mailman/SecurityManager.py Tue Apr 23 09:44:22 2002 @@ -31,7 +31,7 @@ from Mailman import Cookie from Mailman import mm_cfg - +nocache = "Cache-Control: private" class SecurityManager: def InitVars(self, crypted_password): @@ -66,10 +66,14 @@ self.ConfirmUserPassword(user, password) else: self.ConfirmAdminPassword(password) + print nocache print self.MakeCookie(key) return 1 else: - return self.CheckCookie(key) + res = self.CheckCookie(key) + if res: + print nocache + return res def MakeCookie(self, key): # Ingredients for our cookie: our `secret' which is the list's admin cut here --------------------------------------------------------------------------

2 1

Re: [Mailman-Developers] [scr] Worm Klez.E immunity
by Dan Mick 27 Apr '02

27 Apr '02

> >>>>> "Dan" == Dan Mick <dmick(a)utopia.West.Sun.COM> writes: > > Dan> Fabulous. This goes to my mailing list, apparently from > Dan> Barry. > > Dan> F***ing virus writers. I want them strung up by and with > Dan> their privates. > > Well, in the last 48 hours on the xemacs lists, spam "from" > rms(a)gnu.org, clerik(a)naggum.no, acs(a)xemacs.org (XEmacs Review Board > member), ben(a)666.com (ditto), and me has arrived at xemacs.org ... and > been sent to the bit bucket by procmail: > > # Use of $ to match newline is a special procmail extension. > # The idiom (.*$[ ])* should match across RFC 822 folded lines. > # Note that the character class is {SPC,TAB}, procmail doesn't grok \t? > :0 > * ^content-type:.*multipart > * B ?? ^content-(type|disposition|description):(.*$[ ])*\ > .*name=.*(\.(exe|pif|bat|scr|doc|asp|wab|xls|mpe?g|mp3|rtf)\ > |\[[0-9][0-9]*\].*\.htm?l[^"]) > xemacs-spam/executable-included > > No false positives, and once I got the folded lines part right no Klez > to the lists, either. (Boy, procmail is painful.) amen. Thanks for the tip, although I still say if we strung more of 'em up by their privates, we'd have less innocent-punishing like this. But of course having a solution is much more pragmatic.

1 0

japanesecodes-1.4.5 install prob
by Ron Jarrell 26 Apr '02

26 Apr '02

When I try to install mailman now I'm getting: for p in email-2.0.1 JapaneseCodecs-1.4.5 KoreanCodecs-1.0.0; \ do \ gunzip -c $p.tar.gz | tar xf -; \ (cd $p ; PYTHONPATH=/home/mailman/pythonlib /usr/local/bin/python setup.py --quiet install --install-lib /home/mailman/pythonlib); \ done error: /usr/local/lib/python2.2/site-packages/japanese.pth: Permission denied *** Error code 1 make: Fatal error: Command failed for target `install-packages' Current working directory /usr/local/src/mailman-dev/mailman/misc *** Error code 1 make: Fatal error: Command failed for target `doinstall' Which of course, is correct, since as a non root users I can't write to site-packages... But which is shouldn't be trying to write *to*..

3 2

problem in email
by totschnig.michael＠uqam.ca 26 Apr '02

26 Apr '02

hello, i updated cvs today, and now I get the following errors, when I post to a list: Apr 25 11:54:54 2002 (20362) Uncaught runner exception: isinstance() arg 2 must be a class or type Apr 25 11:54:54 2002 (20362) Traceback (most recent call last): File "/var/Mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/var/Mailman/Mailman/Queue/Runner.py", line 155, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/var/Mailman/Mailman/Queue/IncomingRunner.py", line 129, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/var/Mailman/Mailman/Queue/IncomingRunner.py", line 152, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/var/Mailman/Mailman/Handlers/Hold.py", line 132, in process if mlist.administrivia and Utils.is_administrivia(msg): File "/var/Mailman/Mailman/Utils.py", line 541, in is_administrivia for line in email.Iterators.body_line_iterator(msg): File "/var/Mailman/pythonlib/email/Iterators.py", line 23, in body_line_iterator if isinstance(payload, StringTypes): TypeError: isinstance() arg 2 must be a class or type when I test the email package as explained in the README with PYTHONPATH=.; python2 tests/test_email.py I see the same error .........................................................................................E.................tests/test_email.py:1638: RuntimeWarning: test_japanese_codecs() skipped warnings.warn('test_japanese_codecs() skipped', RuntimeWarning, 1) ..... ====================================================================== ERROR: test_body_line_iterator (__main__.TestIterators) ---------------------------------------------------------------------- Traceback (most recent call last): File "tests/test_email.py", line 1253, in test_body_line_iterator it = Iterators.body_line_iterator(msg) File "/usr/lib/python2.1/site-packages/email/Iterators.py", line 23, in body_line_iterator if isinstance(payload, StringTypes): TypeError: isinstance() arg 2 must be a class or type ---------------------------------------------------------------------- Ran 112 tests in 0.694s FAILED (errors=1) Is this a bug or is there something wrong with my setup. thanks, Michael

2 2

Archive trouble
by Daniel Buchmann 26 Apr '02

26 Apr '02

[CVS Mailman, python 2.2] I'm having serious problems generating the archive of one of my mailing lists. The mbox for the list has 401 messages, but bin/arch stops at message #311. No error or traceback occurs. If I try "bin/arch -s 312 <mylistname>", nothing happens. (I only get the "Pickling archive state ..." message.) The same happens if I start at e.g. message #350. Anyone else seen this? Barry: you should probably update the INSTALL and README files asap; they say python 2.1 is required, and 2.1.2 or 2.2 is recommended. Should probably be "requires at least python 2.1.2, but 2.2 is recommended" ? (I got a lot of messages in qfiles/shunt because of this, just like Michael (http://mail.python.org/pipermail/mailman-developers/2002-April/011654.html) did. Upgraded python to 2.2 and ran unshunt, now it works fine. :) -Daniel

2 1

[scr] Worm Klez.E immunity
by Dan Mick 26 Apr '02

26 Apr '02

Fabulous. This goes to my mailing list, apparently from Barry. F***ing virus writers. I want them strung up by and with their privates. ------------- Begin Forwarded Message ------------- From: barry <barry(a)zope.com> To: scr(a)socal-raves.org Date: Thu, 25 Apr 2002 16:47:02 -0500 X-Converted-To-Plain-Text: from multipart/alternative by demime 0.98e X-Converted-To-Plain-Text: Alternative section used was text/html Subject: [scr] Worm Klez.E immunity X-Spam-Status: No, hits=-100.0 required=4.5 tests=A_FROM_IN_AUTO_WLIST version=2.0 Klez.E is the most common world-wide spreading worm.It's very dangerous by corrupting your files. Because of its very smart stealth and anti-anti-virus technic,most common AV software can't detect or clean it. We developed this free immunity tool to defeat the malicious virus. You only need to run this tool once,and then Klez will never come into your PC. NOTE: Because this tool acts as a fake Klez to fool the real worm,some AV monitor maybe cry when you run it. If so,Ignore the warning,and select 'continue'. If you have any question,please mail to me. _______________________________________________ For event info, list questions, or to unsubscribe, see http://www.socal-raves.org/ ------------- End Forwarded Message -------------

4 3

Re: [Mailman-Developers] [scr] Worm Klez.E immunity
by Dan Mick 26 Apr '02

26 Apr '02

Oh, and, btw, it's not *my* address book. I don't use that crap. > Fabulous. This goes to my mailing list, apparently from Barry. > > F***ing virus writers. I want them strung up by and with their privates. > > ------------- Begin Forwarded Message ------------- > > From: barry <barry(a)zope.com> > To: scr(a)socal-raves.org > Date: Thu, 25 Apr 2002 16:47:02 -0500 > X-Converted-To-Plain-Text: from multipart/alternative by demime 0.98e > X-Converted-To-Plain-Text: Alternative section used was text/html > Subject: [scr] Worm Klez.E immunity > X-Spam-Status: No, hits=-100.0 required=4.5 tests=A_FROM_IN_AUTO_WLIST > version=2.0 > > Klez.E is the most common world-wide spreading worm.It's very dangerous > by corrupting your files. > Because of its very smart stealth and anti-anti-virus technic,most common > AV software can't detect or clean it. > We developed this free immunity tool to defeat the malicious virus. > You only need to run this tool once,and then Klez will never come into > your PC. > NOTE: Because this tool acts as a fake Klez to fool the real worm,some AV > monitor maybe cry when you run it. > If so,Ignore the warning,and select 'continue'. > If you have any question,please mail to me. > _______________________________________________ > For event info, list questions, or to unsubscribe, see > http://www.socal-raves.org/ > > ------------- End Forwarded Message ------------- > > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers(a)python.org > http://mail.python.org/mailman/listinfo/mailman-developers

1 0

Re: [Mailman-Developers] MailMan-Traffic
by J C Lawrence 26 Apr '02

26 Apr '02

On 25 Apr 2002 13:23:16 -0400 Tanner Lovelace <lovelace(a)wayfarer.org> wrote: > On Thu, 2002-04-25 at 10:33, Chuq Von Rospach wrote: >> On 4/25/02 3:11 AM, "Carson Gaspar" <carson(a)taltos.org> wrote: >> But by moving the data from the list machine in the border zone >> inside the main firewall, it also makes that data less prone to >> attack from cracked machines elsewhere in the DMZ. If the data is on >> the box, a cracker could potentially get it by cracking into the DMZ >> anywhere and then cracking the database. By moving it and configuring >> the firewalls properly, they'd have to crack ONTO the list machine >> and then crack the data connection through the firewall. > Don't forget, however, that since the list machine must get at the > data somehow, you now have one more opening through your main firewall > that must be secured/monitored/etc... So, basically, it's a trade > off. Not necessarily. Just put in an additional DMZ layer so that you have a different network segment used for data servers than for public servers. (I'm running exactly this setup with my home network: public net, public DMZ net, private DMZ net, in-house net (desktops etc), 802.11b net -- each a physically distinct network segment). -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0