Mailman 3 August 2013 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett Nov. 7, 2022

Nov. 7, 2022

Hi. There's a fairly simple problem here that needs to be addressed. And it's mostly a documentation/install problem. I'm hoping we can get this resolved before the next release. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But because it comes stock this way, and is documented to install this way, most people install it to do this. Those of us who work in abuse departments are tired of hearing "well that's how Mailman … [View More]

21 168

Mailman 2.1.16 release.
by Mark Sapiro Nov. 23, 2013

Nov. 23, 2013

FYI, I will be releasing 2.1.16rc1 in a few days with a target of a final release in early September. I believe the release will be very solid and stable. The main purpose of the candidate release is to expose any i18n changes so that translators can submit any updates and get them in the final release. There are a few new features, contributed programs, i18n changes and bug fixes, all of which will be announced when the candidate is released. -- Mark Sapiro <mark(a)msapiro.net> … [View More]

4 10

Can we send message with attachment using UserNotification?
by Nghia Vu Truong Sept. 2, 2013

Sept. 2, 2013

Hi there, Could you please help me with this question! Is there anyway we can attach a document to message, sending by UserNotification method? Thanks Nghia

3 2

GSoC Updates
by Abhilash Raj Aug. 30, 2013

Aug. 30, 2013

Hi all, So I think my work inside mailman for signing and verification is almost complete, here are a few things that I have now working and it would be very nice if some of you can have a look at the code and let me know if the implementation is correct(the logical and the pythonic way). 1) There is a 'signature rule'[1] that can verify signature from the users whose public key is stored in 'var/gpg' directory insider 'pubring.gpg'. This rule also verifies that the email has only two parts … [View More]one of which must be 'application/pgp-signature'. 2) The 'signmessage handler'[2] signs the message while preserving the sender's signature. The structure of the message for now is a multipart/alternative with each alternative part having one signature(one from list and another from sender). (I have into my todo what Daniel suggested previously[3] to have two signatures in one pgp-signature part) 3) A 'gpg'[4] utility which does all the crypto part from signing to verification, generation of list's key, importing key from data(will be used if we allow user's to copy paste their public key data insider postorius), importing key from a public keyserver(default is set as 'pgp.mit.edu' on random basis, please suggest something which you think can be a better default). In line 81 I am passing an empty string to the comment for the key but still the key generated is still having the default comment 'Generated by gpg.py'. Any idea why? Is it because the string I am passing is a null string and it should have a non-null string to set as comment? 4) There are few other changes like adding the signature rule in default-posting-chain chain and signmessage handler in default-posing-pipeline. Also I have added a new config variable as 'gpg_dir' whose default value is set to '$VAR_DIR/gpg'. There are tests written for almost all the modules above, some more tests maybe required to be added to then though) I am thinking to setup a working installation of this code once I find a place to do that, so that we can find bugs more easily. Moving on my plan includes adding the APIs for management of keys and options for list-admin and users in postorius and mm-client. If anyone has ever given a thought before about what all things should be there please help me with it. [1]: http://bazaar.launchpad.net/~raj-abhilash1/mailman/master/view/head:/src/ma… [2]: http://bazaar.launchpad.net/~raj-abhilash1/mailman/master/view/head:/src/ma… [3]: http://www.mail-archive.com/mailman-developers%40python.org/msg13961.html [4]: http://bazaar.launchpad.net/~raj-abhilash1/mailman/master/view/head:/src/ma… --- Abhilash Raj [View Less]

3 4

virtualenv and nose2 replace zc.buildout and zope.testing
by Barry Warsaw Aug. 28, 2013

Aug. 28, 2013

Hey everyone, A while ago I mentioned that I was trying to get rid of zc.buildout to build Mailman 3 and zope.testing to test it. This work is now complete and pushed to trunk. My thanks to the awesome nose2 project and Jason Pellerin for his help in answering my questions along the way. Updated instructions are available in src/mailman/docs/START.rst and it would be great if you could test this out. Here's a summary. * Create a virtual environment using Python 2.7 % virtualenv --… [View More]

2 1

ANN: wiki.list.org migrations
by Barry Warsaw Aug. 23, 2013

Aug. 23, 2013

Hello everyone, I want to mention a few things related to wiki.list.org. First and most immediately, our currently wiki hosting provider Contegix, is in the process of a major infrastructure update which will cause some downtime for wiki.list.org. Contegix has been hosting our wiki gratis for several years, for which we are very grateful. Their support over the years has been superb. Unfortunately, the infrastructure our wiki is hosted on is quite legacy, and in fact, we are the last … [View More]

1 0

Fwd: Re: GSoC Updates
by Abhilash Raj Aug. 22, 2013

Aug. 22, 2013

-------- Original Message -------- Subject: Re: [Mailman-Developers] GSoC Updates Date: Thu, 15 Aug 2013 19:44:43 +0530 From: Abhilash Raj <raj.abhilash1(a)gmail.com> To: Stephen J. Turnbull <stephen(a)xemacs.org> Thanks for the replies, I tried working on it and it was good enough to be used for now. Thanks Steve for trying it yourself. I have another few set of question now as I move towards signing and a few answers to it also(which may be wrong please correct me). 1) How do … [View More]list owner create keys? What parameters? Which address? I think I will write a small doc on how to create key via command line in linux using gnupg and copy paste the ascii armoured text to postorious ui(which will be created soon). About the address I think owner can create a key using posting address with a min key length of 1024? or else mailman rejects the key? MD5 hash should be discouraged and at least SHA1 should be used?(although I found this[1] that even sha1 should not be used) 2) RSA or DSA keys? DSA can only be used for signing but is faster than RSA, although for now our scope is limited to signing later on we "will" add encryption so I think we should stick to RSA? 3) How to manage paraphrase(or passwords) for keys? In previous discussions we decided to use gnupg-agent and I although I haven't tried it. Any other suggestions to it? Also one more thing while running tests i noticed many other tests are breaking as initially a simple message could pass though "default-posting-chain" but now we need a multipart/signed message. So should I worry about changing all other tests? --- Abhilash Raj [1]: http://lwn.net/Articles/337745/ On Wednesday 14 August 2013 02:05 PM, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > > After midterm evaluations I have been working on signing the message > > using one the keys associated with the list, now since `python-gnupg` > > does not allow selecting keys with key credentials( like address or > > list-name name) > > Have you tried this? In the GPG documentation, "key ID" often > actually means any of the above.[1] If python-gnupg simply passes its > argument to the gpg process, it should Just Work. Anyway, it seems to > work for me (some output edited for clarity): > > venv27 abhilash 15:39$ python2.7 > Python 2.7.5 (default, Aug 1 2013, 23:58:20) > [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > No entry for terminal type "emacs"; > using dumb terminal settings. >>>> from gnupg import GPG >>>> gpg = GPG(gnupghome='/Users/steve/.gnupg',keyring='test-pub',secret_keyring='test-sec') >>>> gpg.list_keys() > [{'dummy': u'', 'keyid': u'17A810C33BDFEFA8', 'expires': u'', > 'subkeys': [[u'2C376F1897FD6C1C', u'e']], 'length': u'2048', > 'ownertrust': u'u', 'algo': u'1', > 'fingerprint': u'A36D6B345C18B02E695B8B7917A810C33BDFEFA8', > 'date': u'1376462161', 'trust': u'-', 'type': u'pub', > 'uids': [u'GPG Test User <gpg-tester(a)turnbull.sk.tsukuba.ac.jp>']}, > {'dummy': u'', 'keyid': u'87EBCC0B6DF8B373', 'expires': u'', > 'subkeys': [[u'18E03AE36F3B6DAD', u'e']], 'length': u'1024', > 'ownertrust': u'-', 'algo': u'17', > 'fingerprint': u'A9FC56DBD48F5E5B61B7137487EBCC0B6DF8B373', > 'date': u'1183228371', 'trust': u'-', 'type': u'pub', > 'uids': [u'Stephen J. Turnbull (XEmacs Reviewer) <stephen(a)xemacs.org>']}] >>>> crypted = gpg.encrypt(u'A bit of random text.', u'stephen(a)xemacs.org', always_trust=True) >>>> str(crypted) > '-----BEGIN PGP MESSAGE----- > Version: GnuPG v1.4.14 > (Darwin) > > hQIOAxjgOuNvO22tEAgAgPUFFCFDKe8zSWt42IG7LkLWWbbTCiAsO7aM2pEgtFrI > KxRklwvEOX7bj5cYbmGr1PeM2IH58T4gMMHsYuOUyNzxS1mbsXZ9C4rpE0QJSkPY > +5Z10dpHEyAZ030g6uBeubFHC+78as1s10UP16zlVgs2AeZwfM88OBocs7FmUdZr > X5uAUxpB5RGET/zc2uHvBzIigXTzUrS8LrTtPfhyP8jCia6klX/2+2Q3gPlENoaP > PkIx/vZ7aKCIKyoP+pbLlwGAb/CX1WoQgyrsNFApg/HJhZ3ZLYKcvIqO3PNejOcN > 8ZYLRV4Uz0tLCuALCccw+XEZSQTKBoemXqVUwSKCAAf+OiHpMqDMoO7ReVVZg841 > MnRcZzfUnL8mj1FZwnr3iTcQ7BdUbu5vMAjn0SIlBISquu0rZi+wynGwgSpWnJeF > Llh+gjizNuHUxtO96phbwMeyVrD1yKSxkxC9cY0r8NBo/MTwUmyMCHNKpj0qrome > GZI2ekhYjLWfAbX3c6dwBx7pQhwkHkgMmoY6yN0OpLf1urnHGpv+AsEwDmWZ8mz3 > CLtD/l9eMl4LGIHNSV7yQ4lAzhYMenNdxkYJyKtxEvM1BFdqOblRb/h+B3X/xtT/ > 6ATAK1mZz1nU4H2EB1EvS4rbbQJ6oIevQSz3r/G6jSI7PqPDJvhnzQBrN7wh1pep > ldJQASeq3bCushTnFolWVxOgswXm2VFMPnhqEVxBJrZ12nZO2LGN7Y2/W+qQ/Qqb > DdYqbYOXNFW9r9p7ugJKKD1kK3XUkTC0Y+t1I/a7dLJBvpA= > =olXg > -----END PGP MESSAGE----- > ' >>>> of = open ('/tmp/cryptfile', 'w') >>>> of.write(str(crypted)) >>>> of.close() >>>> signed = gpg.sign('A bit of random text.', passphrase=u'Not useful without my keyring.', keyid=u'gpg-tester(a)turnbull.sk.tsukuba.ac.jp') >>>> str(signed) > '-----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > A bit of random text. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 > (Darwin) > > iQEcBAEBAgAGBQJSCz30AAoJEBeoEMM73++oWGcH/jS3AJ6OZLm8JHiLAI0AzCXe > muRVhPPfGrqL/Jr+l9WA8Zj3pClHa04H0ha3nvYFHPhN30lFDDw56iCPMA+DbJbr > 2BeqUSfJj36EGHOi8yV5iljZA4NhAw9qqhwQz7kas+KTeY8+98DQDS10ixVZ92Gv > NDxQCKcyTj+6leqy3ePRAgXP5DouTGXntupzPQzcbQW6L8X6h6STOiLAAGKXpGJm > t4Fruvbb3kAcqDGCp5Y9kLrxd1unlCp9leoeJeG5NZ5IcI2B4qUwqKdydu9ZMJxS > kJYJR1ZNVMtQh/kMNA87GMNv4nd8d5QPD+bm5b4L5BDlibzMGb5Q80mJAKD5xqo= > =qHjE > -----END > PGP SIGNATURE----- > ' >>>> > > Decryption of the encrypted file works. I didn't verify the > signature, but it looks like it's working. > > > Also I understand that keeping key safe is one of the important > > tasks but for the time-being I am simply adding the public and > > secret keyrings in "VAR_DIR/gpg/", all the list's private keys are > > in `secring.gpg` and all the list's public keys are in > > `pubring.gpg` and all the user's public keys are in > > `userring.gpg`. It will be changed to keep the secret keys at a > > more safer location. > > I agree with Richard that there's no particular reason to do anything > but put the public keys on one ring. > > I don't see any point in putting the private keys somewhere else. As I > wrote elsewhere, the weak point in the private keys is the need to > supply a password, not the location of the file containing the key. I > wonder if there may not be a way to do this using agent forwarding so > that the private keys are kept on a different host. > > The only issue I can see is that *if* at some point it becomes > feasible to use agent forwarding, I suspect only one agent can be used > per GPG subprocess. > > > Footnotes: > [1] Has anybody else noticed that both gpg's UI and its documentation > seem designed to make it as hard to use as possible? > [View Less]

3 2

Some Doubts for GSoC Project
by Abhilash Raj Aug. 22, 2013

Aug. 22, 2013

Hi, I had a few doubts regarding the project, I din't see any reply on mm-dev so I mailed separately. Firstly what address should be used to create the keys for the lists? I was of the opinion that list' posting address should be used like 'mailman-developers(a)python.org' for mm-dev list. Steve had opinion that keys should be associated with people rather than bots so the address should be '$LIST-owner@fooo' type. Any thoughts?? Also Barry while running tests I see a few tests are failing … [View More]

6 7

Fwd: Re: GSoC Updates
by Abhilash Raj Aug. 22, 2013

Aug. 22, 2013

-------- Original Message -------- Subject: Re: [Mailman-Developers] GSoC Updates Date: Fri, 16 Aug 2013 11:48:56 +0530 From: Abhilash Raj <raj.abhilash1(a)gmail.com> To: Stephen J. Turnbull <stephen(a)xemacs.org> On Friday 16 August 2013 10:35 AM, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > > 1) How do list owner create keys? What parameters? Which address? > > python-gnupg provides a key-generation API, GPG.gen_key(). > Alternatively, this could … [View More]be done manually by the trusted > site-manager. The web UI would have to run over SSL, presumably > HTTPS. But can we achieve required randomization to create keys on virtualized systems? This was the reason it was suggested before that keys are uploaded by the site owners when they create new lists. > I think the address should be $LIST-owner@fqdn. For other parameters, > defaults are OK I think (size=2048, type=RSA IIRC). > > > About the address I think owner can create a key using posting > > address with a min key length of 1024? or else mailman rejects the > > key? MD5 hash should be discouraged and at least SHA1 should be > > used? (although I found this[1] that even sha1 should not be used) > > Nobody short of a major government can afford to break private keys or > crypto hashes on a regular basis. Otherwise, before they try to break > SHA1, they'll kidnap and torture you (I'm serious about the > calculation they'll make, not that I think it will happen to anybody > we know for several thousand years). Okay then we can just suggest not to use md5. > > 3) How to manage paraphrase(or passwords) for keys? > > > > In previous discussions we decided to use gnupg-agent and I > > although I haven't tried it. Any other suggestions to it? > > I really don't know. As you probably know, files containing host keys > for SSH and other SSL applications don't have passwords, but are > simply made readable only by root. That might be the appropriate > solution here. Otherwise, any reboot takes all lists down until the > owner can be tracked down. > > > Also one more thing while running tests i noticed many other tests are > > breaking as initially a simple message could pass though > > "default-posting-chain" but now we need a multipart/signed message. So > > should I worry about changing all other tests? > > Yes. Conventionally that is the responsibility of the person who adds > a feature. However, there's nothing that says you can't ask Barry for > help. He may know a way to do it quickly. Barry anything here? [View Less]

2 4

GSoC Updates
by Abhilash Raj Aug. 21, 2013

Aug. 21, 2013

Hi all, After midterm evaluations I have been working on signing the message using one the keys associated with the list, now since `python-gnupg` does not allow selecting keys with key credentials( like address or list-name name) so we need key_id. As barry suggested we can create a mapping of address to key_ids and store in a seperate table. I was of the opinion that we need key_ids only for signing the content and hence need to select only list's keys and not user, so can we add a new … [View More]

6 7