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> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
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
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
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
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 --system-site-packages /tmp/py27
* Activate the virtualenv and set it up for development
% source /tmp/py27/bin/activate
% python setup.py develop
* Run the tests
% nose2 -v
This makes building for development consistent with building for (test)
deployment, and simplifies Mailman 3's dependencies, and some implementation
details are nicer now.
Enjoy, and please let me know if you have any problems.
-Barry
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 organization to be hosted on it. The time has come
to for them to retire it, but they have again graciously offered to continue
hosting our wiki gratis on their new infrastructure. The migration process is
tricky, since we have to coordinate with Contegix's timing and our DNS changes
with John Viega (Mailman's original author and owner of the list.org domain).
Please be aware that the wiki may experience some downtime as both DNS and the
instance get shuffled around.
As some of you know, Paul Boddie has been working diligently on migrating our
current Atlassian Confluence wiki to Moin. While Confluence has served us
well over the years, we recognize that it is inappropriate for a GNU project
such as Mailman to utilize a non-free wiki. Moin is our current choice for a
free software wiki hosting platform, and Paul has done an amazing job on the
migration, as anyone who reads mailman-developers can see. That work is
close, but not quite ready for production. Stay tuned for more announcements
on that front, or join mailman-developers for more information, or if you'd
like to pitch in to help.
We will send another announcement when the Contegix transfer is complete. In
the meantime, if you see outages for wiki.list.org, please be patient. I hope
there won't be too much of a disruption of service.
Cheers,
-Barry
-------- 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 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?
>
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 because now
simple message will not be able to pass the 'default-posting-chain' and
'multipart/signed' is requred. So should I change all the tests?
----
Abhilash Raj
-------- 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 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?
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 column `key_id` to the existing list table? So that the key_id is
easily accessible as a list parameter and can be easily updated. One
point in this would be should we allow more than one key associated with
a user( or address? ).
Any comments on this? (barry?)
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.
---
Abhilash Raj
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm having some trouble in interacting with preferences as they are
exposed via Mailman's REST API. As I understand from the
documentation, preferences have various "fallbacks" so a value is
always available even if it is not present for an upper level. This
goes as: member -> address -> user -> system.
Onwards to the problem: To change a value in the preferences of a
membership.
It would seem that the membership preferences (accessible via
"/members/id/all/preferences") are set as read-only. So when I do this:
>>> requests.patch(url, data={'delivery_mode': "digest"},
>>> auth=auth)
It returns 405. Although we can modify "delivery_mode" if we access
"/members/id/preferences".
So how do I change those other values? I can try and convert them on
the Address, or the User, but those are not specific enough. Something
like Address would change them for *all* the subscriptions on that
email address, which is not the goal here.
And maybe I'm missing something, but it would also seem that changing
them on a address would be pointless if we have a membership, since,
as the docs say, precedence is given to
the membership preferences (which can't be modified).
So, why are membership preferences read-only and is there anything I
can do about that?
Thanks!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSFLvwAAoJEDTnrae/jUU9gOgH/R0/KcXyNv6hE/gWiT4JN9Vs
lranOJ8Iu45iEPbHUP1OZ1V+qJtr7GIAMH+oN/n0dK7lWMTDWmx3tKowaXWODt6t
6DVFceyMItwPUTaIiWI8xtmjZWbBhbNTc11dsaDMcEbegrPLur2QtdQYpnHFXO9x
EgBe4F6ZGdLhFxIy0xwmMupTtJRG/1c00r5LCSIhMQrZ5n1ywFZEG7WRMX9hj1sB
qKuTMGnGS1ydLnJrQ0RmbEstHWk9AuzxWzlP+1k+LBcdA3X6t5GvedM61Jz+6uTA
cPRBNRZSZZLaWXQheXGnnKZ1ioY3EX7YhhAp4sRvspKqvQVTEt2MNmKgBzktP7I=
=ysZD
-----END PGP SIGNATURE-----
