[Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration

[Barry Warsaw]

Stephen's already given a very good response, so I'll just add a few more
thoughts.

On Jun 15, 2013, at 11:12 AM, Abhilash Raj wrote:

>* How to ensure the keys belong the email it says it does?
>
>  One method proposed for this was to send a confirmation email to the email
>  address, but what if the email is intercepted in between and the attacker
>  confirms the sign up of the person he is trying to impersonate? Or
>  this is a problem that can be solved with SSL and is not of our concern?

One thing you could do is to send a confirmation message encrypted to that
public key.  You'd have to make sure that the confirmation token is *only* in
the encrypted part (e.g. you could not include the token in the Subject header
as we currently do for convenient "just hit reply" functionality).

The point is that if Mailman has the public key, because they user just
uploaded it, then the intended recipient must have the private key.  If you
encrypt the confirmation token to this public key, then the recipient's
private key should be able to decrypt it.  An evil interceptor wouldn't have
that private key and thus would not be able to hijack anything.

>* Inline pgp should be supported or not?

Probably not as a first step.  PGP/MIME will be easier to support so do that
first.  As Stephen suggests, a survey of popular MUAs might be useful.  My own
(Claws Mail) supports them both, though I'm not sure which is default.  I
certainly use and prefer PGP/MIME.

>* Should mailman keep the signature of sender before signing or strip if off?

You'll want to look at the IMailingList.anonymous_list flag.

>I think the function to prase message, check signature, resign message
>could be there in utilities as a gpg.py module. Which is where I think I
>should first start from. I was looking for a python wrapper for gnupg
>and found two options: [python-gnupg][2] and
>[gnupg-interface][3]. GnuPG-Interface was what was used in pgp-smime
>patch for mailman 2.1.5. I don't have much idea about waht should be
>used, will post on mailman-developers.

Please use python-gnupg.  I've been using it lately for a different project
and I think it's very solid, with a nice API.  Plus, it's actively maintained
by a good developer who is responsive to bugs and feature requests.  Plus,
it's Python 3 compatible. :)

I think it does make sense to put some primitives in a utilities/gpg.py
module.  The things that should go in here are probably higher level APIs that
Mailman itself will find useful.  Be sure that anything that goes in here has
a unit test (at least) and possibly a doctest.

>About the outgoing messages i was thinking if we can create a signing
>queue and sign runner which simply signs each message with list's
>private-key and then the message moves on to outgoing queue where it can
>be delivered without any furthur changes. Any ideas about this?

I'm with Stephen here, I don't think a separate queue is required.  A new
queue implies another runner, which means another process that must be
managed.  Signing isn't *that* much of a bottleneck that adding it will gum up
the works too much.

I think it would be okay to sign the message once for all recipients, even if
we're doing personalization.  The personalized parts will have to go in the
unsigned bits though (e.g. the headers and any user-specific footer parts).
If not, then the outgoing signatures will have to be added by the mta
component so that it signs the final message before it's sent to the upstream
MTA for delivery.

-Barry