combination of text-mode signature (by mutt?) and gpg >= 1.4.8 introduces interoperability problem

[Bernhard Reiter]

Am Dienstag, 8. Juli 2008 15:02:56 schrieb David Shaw:
> On Jul 8, 2008, at 4:11 AM, Bernhard Reiter wrote:
> > Just followed up on an email written with mutt 1.5.18
> > and signed with gnupg 1.4.9 which I could verify the signature
> > with gpg2, but not with gpg1 from Debian Sarge and Etch
> > which is 1.4.1 and 1.4.6 with patches respectively.
> >
> > My current hypothesis is that the default change
> > introduced in gnupg 1.4.8 regarding --no-rfc2440-text
> > causes the interoperability problems. From what I have gathered,
> > the new setting is --no-rfc2440-text which will not strip
> > trailing spaces and tabs.
> >
> > So verification with at least 1.4.1 - 1.4.7 fails with default
> > settings, if lines with trailing spaces and tabs are left in
> > unquoted by the MTA.
> > As the email came from mutt 1.5.18, I could observe that trailing
> > spaces were left in, in an message/rfc822 part.
> > (Note that quoted-printable or base64 is forbidden in those parts.)
> > Mutt could have stripped the spaces in this case before calculating
> > the hash, but did not and this is hard to decide, because any  
> > message/rfc822
> > part might contain another signature.
>
> Can you clarify a bit more what you are seeing?  I think if there was  
> a general problem here we would have heard screaming from many  
> sources.  Since you're the first person reporting it here, I wonder if  
> there is something more subtle going on.
>
> Specifically:
> * Are you sure the sending MUA is mutt 1.5.18?  (The subject line says  
> "by mutt?" which suggests you're not sure).

Yes, I am quite sure as the header has it 
and I do not think this is manipulated.
I've used the question mark to indicate that I do not know how
much mutt contributes to the problem. 

Note that you would need to have an attachment in, that already
has trailing spaces to some lines. Maybe it must be a message/rfc822 
attachment, I did not verify yet.

> * What is the receiving MUA? (the one which calls GPG to verify the  
> signature).

I've tried several e.g. mutt and used gpgparsemail as well. 
Then I've disassembled this is msg and msg.sig and thus 
are using gpg and gpg2 directly on these files.
gpg --verifiy msg.sig fails. gpg --no-rfc2440-text --verify msg.sig
works, as does gpg2.
(gpg is gpg 1.4.1 or 1.4.6 from Debian Sarge and Etch).  

> * Was this message sent OpenPGP/MIME or something else?  Clearsigned?  
> An old-style armored blob containing the content plus appended  
> signature?  There are (alas) many ways to send a signed mail.

OpenPGP/MIME (which is clearsigned for message/rfc822).

> If you can send me the message in question, that would be ideal.  In  
> mutt, do a ":set mbox_type=mbox", save the message to a file, tar the  
> file to ensure that nothing will mess about with line endings in  
> transit, and send me the tarball.  If the message is sensitive and  
> should not be seen by others, can you ask the sender to create another  
> message in the same way to send me?

I'll ask the sender, as the contents is sensitive and contains a forwarded
message and another attachment.

Best,
Bernhard
 

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner