[Mailman-Developers] PGP-signed message verification using the email module (and in Mailman)

Paul Boddie paul at boddie.org.uk
Thu Jan 9 01:49:14 CET 2014


On Wednesday 8. January 2014 19.21.12 Daniel Kahn Gillmor wrote:
> On 01/08/2014 12:35 PM, Paul Boddie wrote:
> > Of course, RFC 3156 warns about the pitfalls of encoding the part that is
> > to be signed,
> 
> It doesn't just warn about the pitfalls.  it states that:
> 
>    Multipart/signed and multipart/encrypted are to be treated by agents
>    as opaque, meaning that the data is not to be altered in any way [2],
>    [7].
> 
> where [2] and [7] map roughly to:
> 
>  [2] https://tools.ietf.org/html/rfc1847#section-2.1
> 
> which reads:
> 
> Security Considerations: [multipart/signed parts] Must be treated as
> opaque while in transit

I'd mostly assumed this because it obviously wouldn't do to just have the 
different parts modified at random. Thanks for making this clear, though!

> and
> 
>  [7] https://tools.ietf.org/html/rfc2480#section-4
> 
> which reads:
> 
>  [email gateways]
>           MUST provide the ability to tunnel multipart/signed and
>           multipart/encrypted objects as monolithic entities if there is
>           any chance whatsoever that MIME capabilities exist on the
>           non-MIME side of the gateway. No changes to content of the
>           multipart are permitted, even when the content is itself a
>           composite MIME object.
> 
> so if python's email module really does mangle this part, it cannot be
> used within RFC-2480-compliant mail gateways.  This is a bug in python's
> email module, and it needs to be fixed.  Have you reported it to the
> python email module?

Well, I reserve the right to be wrong about this, but it is certainly the case 
that calling as_string on a Message causes the message to be formatted anew.

Whether it is sensible that I use as_string at all is a reasonable thing to 
question - I steadily make new discoveries about the email API as time passes 
- but in effect I'd like to extract the content and signature parts and then 
pass them to gpg. I'm not using the gnupg module that I think the GSOC work 
uses, partly because I started out with my own wrapper, but the issue of 
extracting the content part as it was originally sent - and signed - is the 
critical factor here and probably outside the scope of the gnupg module 
anyway.

There's also the matter of whether any gateway would parse and serialise 
messages in the way I am attempting, but in principle I think that anyone 
using the email module to do so would need to do things the same way unless 
there's another way I'm not aware of. Again, I'd only be too happy for someone 
to tell me I'm doing things wrong. ;-)

I just searched for bugs reported about this and found the following:

http://bugs.python.org/issue1974 (covers the change from tab to space indents)
http://bugs.python.org/issue1372770 (covers issues of header folding)
http://bugs.python.org/issue11492 (also covers header folding)
http://bugs.python.org/issue1440472 (actually mentions a lack of idempotency)

I think the last one probably answers my question, but I'll look at it again 
tomorrow. This may mean that I have to write my own message serialiser, of 
course.

Thanks for looking at this!

Paul


More information about the Mailman-Developers mailing list