[Mailman-Developers] GSoC Updates

[Daniel Kahn Gillmor]

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

-------------- 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/20130830/fc4ddd7e/attachment.sig>