[Mailman-Developers] GSoC Updates

[Stephen J. Turnbull]

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!