[Mailman-Developers] GSoC Updates

[Stephen J. Turnbull]

Daniel Kahn Gillmor writes:
 > 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

Windows users get another reason to switch? ;-)

That should be handled by content filtering.  *However*, content
filtering needs to be taught to throw away the signature too if a
signed part gets filtered.

 > 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.

Sure, but there's a GSoC scope issue here.  Principle Number One has
to be "Better Safe than Sorry", and this is easy for Abhilash to
implement safely.  It has to be an option, of course, for admins
willing to risk junk getting through (eg, because their users don't
use Outlook [Express]).

 > 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?

I doubt that Abhilash knows, and I know *I* don't. :-)

My guess is that signature check in principle is going to be a Rule,
while part-stripping is a Handler.  I don't think Handlers can REJECT,
Rules make that decision, and they come first, before the Handlers.

So I see the process as involving two Rules.  The first one checks the
multipart/signed message itself.  If invalid (either a broken
signature or signer is not allowed to post), DISCARD (the risk of a
spoof is too great).

The second one checks the structure of the message.  Presumably code
can be reused from elsewhere to do this with more accuracy as you
suggest, but the easy check is to disallow multiparts nested in
multipart/signed.

My proposal at this point is to accept an easy and safe (==
restrictive) implementation for the purposes of GSoC and early beta
testing.  I don't mean to suggest it's at all satisfactory for a
public release of this feature (although we might all be surprised and
find out that it's fine for many purposes!)

Steve