Broken digital signatures on mailing lists

Broken digital signatures on mailing lists

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

Hi!

Almost all of my emails are digitally signed (using GnuPG with
OpenPGP/MIME). However, as I receive my own emails over the toolchain
mailing lists (binutils, gcc, gcc-patches), some fail signature
verification.

  It seems some software in between tries to re-encode or fix the
email body, which in turn will break signatures.

  All the body text is encoded as
	Content-Type: text/plain; charset=utf-8
	Content-Disposition: inline
	Content-Transfer-Encoding: quoted-printable
so all "long" lines will be be soft-broken conforming to the
quoted-printable encoding.

  Within any line (original lines as well as generated soft-broken
lines, a leading ASCII dot is specifically handled and always encoded
to "=2E", while other occurrences are used verbatim.

  Re-encoding the message body's content on the fly isn't wrong per
se, but for signed emails, it will break the signature. As an example,
this line would (or probably will, since I guess "overseers" is also a
mailing list) break the signature:

123456789012345678901234567890123456789012345678901234567890123456789012345.7890

(This is 75 regular printable ASCII characters, the line is too long,
so "=" is added and the trailing ".7890" is placed onto it's own soft
line, with the "." being encoded to "=2E", because it's at the start
of the line.)


So...  Maybe there's a chance the mailing list software can be
configured to not re-encode bodies?

Thanks,
  Jan-Benedict

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
  Signature of:                        Lauf nicht vor Deinem Glück davon:
  the second  :                             Es könnte hinter Dir stehen!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Broken digital signatures on mailing lists

[Ian Lance Taylor]

Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:

> Almost all of my emails are digitally signed (using GnuPG with
> OpenPGP/MIME). However, as I receive my own emails over the toolchain
> mailing lists (binutils, gcc, gcc-patches), some fail signature
> verification.
>
>   It seems some software in between tries to re-encode or fix the
> email body, which in turn will break signatures.
>
>   All the body text is encoded as
> 	Content-Type: text/plain; charset=utf-8
> 	Content-Disposition: inline
> 	Content-Transfer-Encoding: quoted-printable
> so all "long" lines will be be soft-broken conforming to the
> quoted-printable encoding.
>
>   Within any line (original lines as well as generated soft-broken
> lines, a leading ASCII dot is specifically handled and always encoded
> to "=2E", while other occurrences are used verbatim.
>
>   Re-encoding the message body's content on the fly isn't wrong per
> se, but for signed emails, it will break the signature. As an example,
> this line would (or probably will, since I guess "overseers" is also a
> mailing list) break the signature:
>
> 123456789012345678901234567890123456789012345678901234567890123456789012345.7890
>
> (This is 75 regular printable ASCII characters, the line is too long,
> so "=" is added and the trailing ".7890" is placed onto it's own soft
> line, with the "." being encoded to "=2E", because it's at the start
> of the line.)
>
>
> So...  Maybe there's a chance the mailing list software can be
> configured to not re-encode bodies?

This doesn't sound like something that the sourceware.org e-mail
software would do.  I agree that your e-mail message, as I received it,
has a broken long line, and thus quite possibly an invalid signature.
But I really can't think of anything on gcc.gnu.org that would re-encode
a MIME e-mail message.

Chris, do you know of anything?  Could the spam filter be doing this for
some reason?

Ian

Re: Broken digital signatures on mailing lists

[Christopher Faylor]

On Tue, Jul 01, 2014 at 03:57:02PM -0700, Ian Lance Taylor wrote:
>Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
>
>> Almost all of my emails are digitally signed (using GnuPG with
>> OpenPGP/MIME). However, as I receive my own emails over the toolchain
>> mailing lists (binutils, gcc, gcc-patches), some fail signature
>> verification.
>>
>>   It seems some software in between tries to re-encode or fix the
>> email body, which in turn will break signatures.
>>
>>   All the body text is encoded as
>> 	Content-Type: text/plain; charset=utf-8
>> 	Content-Disposition: inline
>> 	Content-Transfer-Encoding: quoted-printable
>> so all "long" lines will be be soft-broken conforming to the
>> quoted-printable encoding.
>>
>>   Within any line (original lines as well as generated soft-broken
>> lines, a leading ASCII dot is specifically handled and always encoded
>> to "=2E", while other occurrences are used verbatim.
>>
>>   Re-encoding the message body's content on the fly isn't wrong per
>> se, but for signed emails, it will break the signature. As an example,
>> this line would (or probably will, since I guess "overseers" is also a
>> mailing list) break the signature:
>>
>> 123456789012345678901234567890123456789012345678901234567890123456789012345.7890
>>
>> (This is 75 regular printable ASCII characters, the line is too long,
>> so "=" is added and the trailing ".7890" is placed onto it's own soft
>> line, with the "." being encoded to "=2E", because it's at the start
>> of the line.)
>>
>>
>> So...  Maybe there's a chance the mailing list software can be
>> configured to not re-encode bodies?
>
>This doesn't sound like something that the sourceware.org e-mail
>software would do.  I agree that your e-mail message, as I received it,
>has a broken long line, and thus quite possibly an invalid signature.
>But I really can't think of anything on gcc.gnu.org that would re-encode
>a MIME e-mail message.
>
>Chris, do you know of anything?  Could the spam filter be doing this for
>some reason?

The spam filter adds a new header but shouldn't do anything to the body.
I checked the DKIM filter in /qmail/bin/qmail-remote but I don't see
anything obvious there.

cgf

Re: Broken digital signatures on mailing lists

[Jonathan Larmour]

On 01/07/14 23:57, Ian Lance Taylor wrote:
>>
>> 123456789012345678901234567890123456789012345678901234567890123456789012345.7890
>>
>> (This is 75 regular printable ASCII characters, the line is too long,
>> so "=" is added and the trailing ".7890" is placed onto it's own soft
>> line, with the "." being encoded to "=2E", because it's at the start
>> of the line.)
>>
>>
>> So...  Maybe there's a chance the mailing list software can be
>> configured to not re-encode bodies?
> 
> This doesn't sound like something that the sourceware.org e-mail
> software would do.  I agree that your e-mail message, as I received it,
> has a broken long line, and thus quite possibly an invalid signature.
> But I really can't think of anything on gcc.gnu.org that would re-encode
> a MIME e-mail message.

As a second data point, I see the entire single line (ending with 12345.7890)
in my MUA, including in what Ian has quoted. In the raw message, I see the
following in the message body:
...123456789012345=
=2E7890

(The ellipsis is my own, as I don't want to reproduce the long line verbatim
in case that gets re-encoded somewhere somehow).

My MUA reports it has a good PGP signature.

Jifl

Re: Broken digital signatures on mailing lists

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 4584 bytes --]

On Thu, 2014-07-03 01:15:22 +0100, Jonathan Larmour <jifl@jifvik.org> wrote:
> On 01/07/14 23:57, Ian Lance Taylor wrote:
> > > 123456789012345678901234567890123456789012345678901234567890123456789012345.7890
> > >
> > > (This is 75 regular printable ASCII characters, the line is too long,
> > > so "=" is added and the trailing ".7890" is placed onto it's own soft
> > > line, with the "." being encoded to "=2E", because it's at the start
> > > of the line.)
> > >
> > >
> > > So...  Maybe there's a chance the mailing list software can be
> > > configured to not re-encode bodies?
> > 
> > This doesn't sound like something that the sourceware.org e-mail
> > software would do.  I agree that your e-mail message, as I received it,
> > has a broken long line, and thus quite possibly an invalid signature.
> > But I really can't think of anything on gcc.gnu.org that would re-encode
> > a MIME e-mail message.
> 
> As a second data point, I see the entire single line (ending with 12345.7890)
> in my MUA, including in what Ian has quoted. In the raw message, I see the
> following in the message body:
> ...123456789012345=
> =2E7890
> 
> (The ellipsis is my own, as I don't want to reproduce the long line verbatim
> in case that gets re-encoded somewhere somehow).
> 
> My MUA reports it has a good PGP signature.

That's actually interesting: It would mean that different email
clients (here: Thunderbird with the Enigmail plugin I guess vs. Mutt)
use different strategies for checking signatures.

  If you see it "all okay", then the sig (on your side) is checked on
the decoded (wrt. Content-Transfer-Encoding) content, while Mutt does
that on the whole body (?) as it was received. (Might the former
impose problems with later-on attached message/multipart parts, so
that unsigned content might be (additionally?) displayed?)

  I just searched a bit harder: There were actually some bugs files
for Enigmail wrongly showing correct signatures (or the other way
around) because it intercepts the message with hooks that aren't
actually at the correct time for interception, because there are no
proper hooks at the proper places.

  Reading RFC3156, it's quite clear that first the overall email is
built up (encoded so that is't only using 7bit ASCII), then the
signature is applied. Ensuring that there's no 8bit data is
specifically done so that no MIME gateways need to change the body for
transferring the email over some more SMTP hops, which would change
the body representation (and thus breaking the signature, as I see
it.)

  So... Anythink I can do tracing through the hops during delivery?




Received: from sourceware.org (server1.sourceware.org [209.132.180.131])                                               
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))                                         
        (No client certificate requested)                                                                              
        by lug-owl.de (Postfix) with ESMTPS id 1BA50F020A                                                              
        for <jbglaw@lug-owl.de>; Fri,  9 May 2014 01:06:39 +0200 (CEST)                                                
Received: (qmail 14668 invoked by alias); 8 May 2014 23:06:29 -0000                                                    
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm                                                               
Received: (qmail 14648 invoked by uid 89); 8 May 2014 23:06:29 -0000                                                   
Received: from lug-owl.de (HELO lug-owl.de) (195.71.106.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with   
        (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 08 May 2014 23:06:28 +0000                                          

(This is from one affected email.) As it seems, there aren't too many
hops there. It's sourceware.org -> ezmlm -> server1.sourceware.org ->
lug-owl.de. Which ezmlm/ezmlm-idx is this? If it's some decent
ezmlm-idx version, there's at least support for decoding/encoding
both quoted-printable and base64 content, but I'm not actually into
it (and I find the sources somewhat hard to follow...)  So: Any way to
intercept emails before and after they're fed through ezmlm to see if
it's happening there?

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
  Signature of:                           Wenn ich wach bin, träume ich.
  the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]