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
Created attachment 89310 [details] example of a PGP/MIME signed mail by kmail
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
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.
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)?
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.
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.