[Mailman-Developers] GSoC Updates

Daniel Kahn Gillmor dkg at fifthhorseman.net
Fri Aug 30 05:24:09 CEST 2013


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130829/5fedd1e1/attachment.sig>


More information about the Mailman-Developers mailing list