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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
