[Mailman-Developers] GSoC updates till midterm
Hi everyone, This will be my second update email to mm-dev after gsoc started, i'll be sending weekly summaries in the future. The ci-tool(please suggest some nice name) is almost finished, i need few more days to get it working on multiple projects under mailman suite. The following parts of ci-tool are working: ./ci-tool --pull project_name ./ci-tool --pull all ./ci-tool --test project_name ./ci-tool --test all ./ci-tool --try project_name The projects under the mailman suite are listed in a config file(currently settings.py) which contains the a dict projects which has further dictionaries to store attributes like path, vcs, src location. For parsing the commands form the command line, i have used argparse module and while implementation of commands, i have created two different files: commands.py and utils.py. In commands, i've declared the classes for various commands like pull, test and try and for making a tcp connection via twisted, two more classes for Client and Factory. In utils.py, i've tried to declare the error classes which i'll be able to differentiate easily and a logging class. The most interesting command in this whole tool is the 'try' command, which will take the diff of the project and send it to the server to test it on the server and run all the tests on different installations (in this case i am using buildbot's slaves). I am able to send the diff to server and test it on a single server and now working on how to send the patches for multiple projects of suite, in case the developer is working on multiple projects(like postorius and hyperkitty) at the same time. That's all for the status report, i have to say that whatever i've done won't be possible without the help of my awesome mentors: florian, stylistica, steve and maxking. The source of my project is available at http://bazaar.launchpad.net/~varun/mailman/ci_tool/files. I try to remain active on #mailman and #mailman-gsoc for most of the daytime under nick 'varun'. Thanks Varun ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
Daniel Kahn Gillmor writes: > On 08/30/2013 12:56 AM, Stephen J. Turnbull wrote: > > The last time I looked (~10 days ago), that was the implementation: > > look only at the message-level Content-Type, ensure it's > > multipart/signed, check that there are exactly two parts and that the > > second is "application/pgp-signature". > > hum, what if the first part is an .exe of type application/octet-stream? :P Windows users get another reason to switch? ;-) That should be handled by content filtering. *However*, content filtering needs to be taught to throw away the signature too if a signed part gets filtered. > Doesn't this seem a little overbroad? what if the message is two inline > parts, one text/plain and one text/x-diff (e.g. the common case of > someone sending a patch to a project mailing list ? I understand > wanting to REJECT if any of the internal parts need to be stripped, but > if none of them need to be stripped, it seems like REJECT is too > heavy-handed. Sure, but there's a GSoC scope issue here. Principle Number One has to be "Better Safe than Sorry", and this is easy for Abhilash to implement safely. It has to be an option, of course, for admins willing to risk junk getting through (eg, because their users don't use Outlook [Express]). > Or is the knowledge about what might need to be stripped not available > at that stage? If the stripping happens later, can we mark a message as > "REJECT if you need to strip" somehow, and get the part-stripping code > to respect that marking and REJECT it there? I doubt that Abhilash knows, and I know *I* don't. :-) My guess is that signature check in principle is going to be a Rule, while part-stripping is a Handler. I don't think Handlers can REJECT, Rules make that decision, and they come first, before the Handlers. So I see the process as involving two Rules. The first one checks the multipart/signed message itself. If invalid (either a broken signature or signer is not allowed to post), DISCARD (the risk of a spoof is too great). The second one checks the structure of the message. Presumably code can be reused from elsewhere to do this with more accuracy as you suggest, but the easy check is to disallow multiparts nested in multipart/signed. My proposal at this point is to accept an easy and safe (== restrictive) implementation for the purposes of GSoC and early beta testing. I don't mean to suggest it's at all satisfactory for a public release of this feature (although we might all be surprised and find out that it's fine for many purposes!) Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
On 08/30/2013 12:56 AM, Stephen J. Turnbull wrote: > The last time I looked (~10 days ago), that was the implementation: > look only at the message-level Content-Type, ensure it's > multipart/signed, check that there are exactly two parts and that the > second is "application/pgp-signature". hum, what if the first part is an .exe of type application/octet-stream? :P > Note that nested multipart parts are problematic. You can't strip > unwanted parts from them (many lists strip .exes, others text/html, > and so on) without breaking the original signature. We need to think > carefully about what policies to support regarding signed multiparts. > I would suggest that the initial default policy should be > > (1) verify the signature, if not DISCARD > (2) if valid AND key belongs to explicitly allowed poster (I think > probably nobody wants open-post signed lists, but what do I know? > ;-) AND signed part is multipart, REJECT with "multipart not > allowed for technical reasons" as reason Doesn't this seem a little overbroad? what if the message is two inline parts, one text/plain and one text/x-diff (e.g. the common case of someone sending a patch to a project mailing list ? I understand wanting to REJECT if any of the internal parts need to be stripped, but if none of them need to be stripped, it seems like REJECT is too heavy-handed. Or is the knowledge about what might need to be stripped not available at that stage? If the stripping happens later, can we mark a message as "REJECT if you need to strip" somehow, and get the part-stripping code to respect that marking and REJECT it there? sorry for the ignorance, just exploring the options. --dkg signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
Daniel Kahn Gillmor writes: > On 08/28/2013 09:37 PM, Abhilash Raj wrote: > > > 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'. > > i'm not sure about this last constraint. It's certainly possible to > have a multipart MIME message with a deeper structure that has more > parts if you're looking at the leaves of the MIME tree. the constraint > should be: main content-type should be multipart/signed; that part > should have exactly two immediate children; the last child should be > application/pgp-signature. The first child could itself be > multipart/mixed or multipart/alternative. The last time I looked (~10 days ago), that was the implementation: look only at the message-level Content-Type, ensure it's multipart/signed, check that there are exactly two parts and that the second is "application/pgp-signature". Note that nested multipart parts are problematic. You can't strip unwanted parts from them (many lists strip .exes, others text/html, and so on) without breaking the original signature. We need to think carefully about what policies to support regarding signed multiparts. I would suggest that the initial default policy should be (1) verify the signature, if not DISCARD (2) if valid AND key belongs to explicitly allowed poster (I think probably nobody wants open-post signed lists, but what do I know? ;-) AND signed part is multipart, REJECT with "multipart not allowed for technical reasons" as reason (3) if valid AND key belongs to explicitly allowed poster, APPROVE (4) otherwise HOLD while we're figuring out a sane UI for configuring more complex policies. > have you tested what messages with this structure look like when viewed > with any MUA that is PGP/MIME-aware? +1 > do you have any examples you could publish, so other people can > test other MUAs? +1 > please do not use pgp.mit.edu [0], it is out of date and > poorly-maintained. Your best bet for reliable, redundant service is to > use ha.pool.sks-keyservers.net. You can read more about this > high-availability DNS round-robin pool on the sks-keyservers > website [1]. Thanks for the suggestion! ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
Hi Abhilash-- I haven't looked at the code much yet, but this is a pretty exciting report! I'm glad to hear everything you've done. On 08/28/2013 09:37 PM, Abhilash Raj wrote: > 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'. i'm not sure about this last constraint. It's certainly possible to have a multipart MIME message with a deeper structure that has more parts if you're looking at the leaves of the MIME tree. the constraint should be: main content-type should be multipart/signed; that part should have exactly two immediate children; the last child should be application/pgp-signature. The first child could itself be multipart/mixed or multipart/alternative. > 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) have you tested what messages with this structure look like when viewed with any MUA that is PGP/MIME-aware? do you have any examples you could publish, so other people can test other MUAs? > 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). please do not use pgp.mit.edu [0], it is out of date and poorly-maintained. Your best bet for reliable, redundant service is to use ha.pool.sks-keyservers.net. You can read more about this high-availability DNS round-robin pool on the sks-keyservers website [1]. [0] https://we.riseup.net/debian/openpgp-best-practices#dont-use-pgp-mit-edu [1] https://sks-keyservers.net/overview-of-pools.php > 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? Take a look at the gnupg module (gnupg.py), which you're relying on, around. around line 976 in my version is the definition of GPG.gen_key_input, which skips "empty" strings: 983 if str(val).strip():# skip empty strings 984 parms[key] = val unfortunately, the rest of that function definition appears to require a comment, inserting one by default if no comment is supplied by the user. I consider this a bug in gnupg.py, we should get it fixed there. I've just opened http://bugs.debian.org/721296 to try to get them fixed in debian, but they should probably be forwarded upstream, but upstream's bugtracker [2] appears to require a google account in order to open a ticket, which i do not have or want. If you have a google account, feel free to forward them upstream. [2] https://code.google.com/p/python-gnupg/issues/list In the meantime, i recommend just hand-crafting the input for gpg --batch --gen-key instead of using gnupg.GPG.gen_key_input() at all. If you're not sure about the format, i recommend reading /usr/share/doc/gnupg/DETAILS.gz on any debian or debian-derived system, or DETAILS in the gpg source [3]. [3] git://git.gnupg.org/gnupg > 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. that would be great! Hope these notes are helpful, --dkg signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] GSoC Updates
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/mailman/rules/signature.py [2]: http://bazaar.launchpad.net/~raj-abhilash1/mailman/master/view/head:/src/mailman/handlers/signmessage.py [3]: http://www.mail-archive.com/mailman-developers%40python.org/msg13961.html [4]: http://bazaar.launchpad.net/~raj-abhilash1/mailman/master/view/head:/src/mailman/utilities/gpg.py --- Abhilash Raj ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
Daniel Kahn Gillmor writes: > On 08/14/2013 04:35 AM, Stephen J. Turnbull wrote: > > Python 2.7.5 (default, Aug 1 2013, 23:58:20) > from gnupg import GPG > gpg = > GPG(gnupghome='/Users/steve/.gnupg',keyring='test-pub',secret_keyring='test-sec') > crypted = gpg.encrypt(u'A bit of random text.', u'step...@xemacs.org', > always_trust=True) > hmm, always_trust=True is probably problematic Of course it is, but I was working with a test keyring. > -- if someone manages to inject another key with the associated > User ID earlier into gpg's keyring, then their key will be used > before the correct key. This is an argument for validity checks on the keyring. The alternative is keeping the email-to-fingerprint mapping in the User database, which is *not* designed for crypto validation. I see no reason to suppose it's easier to attack the keyring that the User database. > fortunately, in the current implementation we're only worrying about > signing, not encryption; so the relevant issue is the choice of secret > key, and we don't expect other users to be able to inject data into the > secret keyring, so this shouldn't be a concern. right? I don't think it's a major concern, period. True, encryption uses the public key, which may be downloaded from a keyserver or entered from the web, making injection attacks plausible. So what? What's the alternative given that the raison d'etre of Mailman is to give users control over their profiles? Note that I don't deny that there are real security issues here, and that in some contexts they are important. But if they are, I have to wonder if Mailman isn't much too complicated to be trusted anyway. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
On 08/14/2013 04:35 AM, 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 ']},
> {'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) ']}]
crypted = gpg.encrypt(u'A bit of random text.', u'step...@xemacs.org',
always_trust=True)
hmm, always_trust=True is probably problematic -- if someone manages to
inject another key with the associated User ID earlier into gpg's
keyring, then their key will be used before the correct key.
I agree that gpg should be able to figure out the key to use given the
e-mail address, but i'm not sure if it necessarily will if there are two
keys which both claim a given User ID and only one has a valid binding
(i.e. a proper OpenPGP certification from a trusted introducer).
so the above test worked, given the keyring that you had, but it might
result in *not* working (e.g. by encrypting to the wrong key) given a
different keyring.
fortunately, in the current implementation we're only worrying about
signing, not encryption; so the relevant issue is the choice of secret
key, and we don't expect other users to be able to inject data into the
secret keyring, so this shouldn't be a concern. right?
--dkg
signature.asc
Description: OpenPGP digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
Abhilash Raj writes: > Then i guess I will simply create a new key with list's credentials > when the list is created, I really think that's best for nontechnical users. Read the article Terri cited on mailman-developers a few days ago. Adding an upload option (non-trivial to implement securely, maybe) or additional key_gen options for generation on the list host should be easy to do for any interested party. > for the users I will import key from any public server and also > give an option to upload pubic key data? Sounds good. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
Abhilash Raj writes: > > I think the address should be $LIST-owner@fqdn. For other parameters, > > defaults are OK I think (size=2048, type=RSA IIRC). > > Here should not the address be the list's posting address? Like for > mm-dev list should it not be "mailman-developers@python.org"? Maybe. But in most cases the sender is not going to be the list, and it's possible to configure the list so that the list-post address doesn't appear in the header. So I don't think it matters much. I just tend to associate signatures with people rather than bots. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
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. > > I think the address should be $LIST-owner@fqdn. For other parameters, > defaults are OK I think (size=2048, type=RSA IIRC). Here should not the address be the list's posting address? Like for mm-dev list should it not be "mailman-developers@python.org"? > > 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). > > > 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. > --- Abhilash Raj ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
On Friday 16 August 2013 12:30 PM, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > > But can we achieve required randomization to create keys on virtualized > > systems? > > Not your problem. We can do it on physical hosts, and that's good > enough. People who care this much about security will be prepared to > pay for it. Generalizing to handle sites that need security but don't > care (yet) is Somebody Else's Problem (maybe even you, but in a post- > GSoC avatar). > > "Requirements creep" is identified as one of the most important causes > of project failure. Learn to say "No." where possible, "It will cost > you USD1,000,000 and 36 months." if you must. (Of course in the > latter case you'll replace those numbers with accurate ones. :-) Then i guess I will simply create a new key with list's credentials when the list is created, for the users I will import key from any public server and also give an option to upload pubic key data? > > Okay then we can just suggest not to use md5. > > Yes. For now, your job is to get the system working and working > securely. The defaults for key-generation are fine. > > > > > 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? > > I guess you didn't notice that you didn't reply to the list? Mailman > project lists don't mung Reply-To, you need to reply to list (if your > MUA has the function) or reply to all. I forwarded two mails to the list which i sent to you by mistake. --- Abhilash Raj ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
Abhilash Raj writes: > But can we achieve required randomization to create keys on virtualized > systems? Not your problem. We can do it on physical hosts, and that's good enough. People who care this much about security will be prepared to pay for it. Generalizing to handle sites that need security but don't care (yet) is Somebody Else's Problem (maybe even you, but in a post- GSoC avatar). "Requirements creep" is identified as one of the most important causes of project failure. Learn to say "No." where possible, "It will cost you USD1,000,000 and 36 months." if you must. (Of course in the latter case you'll replace those numbers with accurate ones. :-) > Okay then we can just suggest not to use md5. Yes. For now, your job is to get the system working and working securely. The defaults for key-generation are fine. > > > 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? I guess you didn't notice that you didn't reply to the list? Mailman project lists don't mung Reply-To, you need to reply to list (if your MUA has the function) or reply to all. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
Barry Warsaw writes: > On Aug 14, 2013, at 05:35 PM, Stephen J. Turnbull wrote: > > >[1] Has anybody else noticed that both gpg's UI and its documentation > >seem designed to make it as hard to use as possible? > > Sadly, I think this is one of the biggest reasons why we've never > seen widespread adoption of signatures and encryption in email. Sure, but the wrappers I've seen don't really help. I get the feeling that they are basically designed around smebody's personal needs with all kinds of bags and kludges added on request. Maybe you can sprinkle RDM with itch powder the next time you see him? I bet he could do for a gpg wrapper what he's done for the email package! }:-} ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
On 13-08-14 2:35 AM, Stephen J. Turnbull wrote: 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? Not only have people noticed, but " Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0" is often required reading for computer security students at Carleton because it serves as a great example of how poor usability can render carefully designed encryption and security completely worthless. " The analysis found a number of user interface design flaws that may contribute to security failures, and the user test demonstrated that when our test participants were given 90 minutes in which to sign and encrypt a message using PGP 5.0, the majority of them were unable to do so successfully. " If you haven't read it, I highly recommend it. It's an easy read, freely available online, and very educational. Obviously this is especially of interest to those talking about PGP and mailman, but it's a good read for anyone who works with code: https://www.usenix.org/legacy/events/sec99/whitten.html Terri ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
I agree with everything written elsewhere by Steve and Richard. On Aug 14, 2013, at 05:35 PM, Stephen J. Turnbull wrote: >[1] Has anybody else noticed that both gpg's UI and its documentation >seem designed to make it as hard to use as possible? Sadly, I think this is one of the biggest reasons why we've never seen widespread adoption of signatures and encryption in email. I'll ignore nefarious reasons like authors of MUAs-for-the-masses in deliberate collusion to make it difficult for the non-Snowdens of the world. In any case, I've always heard that gpg deliberately does not expose a programmable API that e.g. could be wrapped by Python. They only provide a command line API because they think that's the best way to avoid incorrect use in language bindings. They're probably not wrong about that. In any case, tools like python-gnupg are essentially glorified subprocess wrappers around the gpg cli, because there's no other way to do it. -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] GSoC Updates
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 ']},
{'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) ']}]
>>> crypted = gpg.encrypt(u'A bit of random text.', u'step...@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-tes...@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?
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mail
Re: [Mailman-Developers] GSoC Updates
Abhilash, I see no reason to have more that one keyring for public keys and another for the private ones. In both cases, those key rings are a flat table indexed by the Key_id. It doesn't matter if the "owner" of the key is a list or a subscriber (or any other user) As for user keys, I think that they should be treated as a ManyToMany relation between the public keys and either the lists or users or, perhaps the subscriptions, in a manner similar to the way that Email addresses are associated with a user. Wacky On Aug 13, 2013, at 9:46 AM, Abhilash Raj wrote: > 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 > ___ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: > http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net > > Security Policy: http://wiki.list.org/x/QIA9 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] GSoC Updates
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 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
