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
