Bug 340321

Summary:	openPGP/MIME Signatures are invalid
Product:	[Applications] kmail2	Reporter:	gigadoc2
Component:	crypto	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	hgeerts
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	example of a PGP/MIME signed mail by kmail signed mail that fails verification on command line and in enigmail-1.7

Description gigadoc2 2014-10-24 21:49:12 UTC

First I should mention I'm actually using kmail 4.14.2, but the bugtracker isn't yet aware of this version.

I am signing my mails with openPGP/MIME for some time now, but since recently, both Enigmail and Sylpheed complain about invalid signatures when recieving mails. I first thought the fault to be with Enigmail, but after testing with numerous other Mailcients, only Horde webmail and KMail itself show my signatures as valid.

After finding a blogpost explaining to me how to verify PGP/MIME with the gpg cli tool (http://emergent.unpythonic.net/01393247437), I did test some of my mails with the provided python script and by manually splitting up the mail into mailpart and signature, and indeed all my mails fail to verify.

Apologies for not providing more information/logs, but I do not know where to look for it.

Reproducible: Always

Steps to Reproduce:
1. Compose Mail with openPGP/MIME signature
2. Save mail in mbox format
3. Split mail at boundaries
4. Verify with "gpg --verify"

Actual Results:
gpg: Signature made Fri Oct 24 23:26:11 2014 CEST using RSA key ID 422DE3FA
gpg: BAD signature from "Fabian Bernhard Pack <gigadoc2@revreso.de>" [ultimate]

Expected Results:
gpg: Signature made Fri Oct 24 23:26:11 2014 CEST using RSA key ID 422DE3FA
gpg: GOOD signature from "Fabian Bernhard Pack <gigadoc2@revreso.de>" [ultimate]

$ gpg --version
gpg (GnuPG) 2.0.26
libgcrypt 1.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA, RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

$ kmail --version
Qt: 4.8.6
KDE: 4.14.2
KMail: 4.14.2

Comment 1 gigadoc2 2014-10-24 21:53:03 UTC

Created attachment 89310 [details]
example of a PGP/MIME signed mail by kmail

Comment 2 hgeerts 2014-11-18 16:55:34 UTC

Created attachment 89627 [details]
signed mail that fails verification on command line and in enigmail-1.7

I have the same problem with kmail 4.14.1 on ubuntu 14.10

Comment 3 hgeerts 2014-11-19 13:32:02 UTC

I just tried to verify my mbox mail with https://www.gnupg.org/documentation/manuals/gnupg/gpgparsemail.html and that seems to succeed the signature check. Which gave me a reason to question the manual method described above as well as enigmail.

I found http://sourceforge.net/p/enigmail/bugs/301/ and forced my coworker to upgrade to the enigmail nightly at https://www.enigmail.net/download/nightly.php and with that version the kmail signature is valid.

Changing the python script to convert line endings from LF to CR LF also makes the signature valid in the manual check.

Comment 4 gigadoc2 2014-11-21 20:56:34 UTC

Well, this adds to my confusion. I can't figure out wether the change in Enigmail 1.8 is really a bugfix or only a compatibility feature for broken clients.

So, is the kmail/gpgparsemail behaviour the right one or that of old enigmail (and basically every other mailclient)?

Comment 5 hgeerts 2014-11-24 16:24:19 UTC

The manual python check was broken anyway since it did not convert newlines to CRLF.

I think the fix in enigmail was commit http://sourceforge.net/p/enigmail/source/ci/8d7fa201ba8bda6f33df348d83923ff0cc876958/tree/package/mimeVerify.jsm?diff=33b2cc9979a933c57430a11ad479108dd04de886
which removes the trailing newline of a mimepart (e.g. if it precedes a mail boundary)

Searching for this lead me to http://bugs.python.org/issue14983 which references https://tools.ietf.org/html/rfc3156#page-5

    Note: The accepted OpenPGP convention is for signed data to end
      with a <CR><LF> sequence.  Note that the <CR><LF> sequence
      immediately preceding a MIME boundary delimiter line is considered
      to be part of the delimiter in [3], 5.1.  Thus, it is not part of
      the signed data preceding the delimiter line.  An implementation
      which elects to adhere to the OpenPGP convention has to make sure
      it inserts a <CR><LF> pair on the last line of the data to be
      signed and transmitted (signed message and transmitted message
      MUST be identical).

So I think this was a bug in enigmail but as is noted in the python bug there seems to be a conflict between the spec and the rfc so it is possible other clients suffer the same problem.
Which other clients failed to verify the signature?

note: this is not my in my field of expertise so it would be great if someone with actual knowledge about this subject could comment on this.

Comment 6 gigadoc2 2014-11-24 23:26:43 UTC

Now I am starting to understand this, thanks for explaining.

The clients failing to verify are Enigmail, Evolution and Sylpheed. I just recently noticed that Claws Mail has an openPGP-plugin, and it actually shows my mails as valid. Apart from those, I don't know any clients with openPGP capabilities.

Anyway, I should probably close this, as it is not a bug in kmail.