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
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
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
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
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 gpg-tes...@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) step...@xemacs.org']}]
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
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
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
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
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
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
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 raj.abhila...@gmail.com 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
