Hello, It appears KMail rewrites some headers within received mails before storing and displaying them. Indeed, a two-parts multipart mail (the first part being the effective message, the second part being the related GPG signature) sent using another MUA (e.g. Mutt) and having the following header in the first part: Content-Type: text/plain; charset=us-ascii ... gets rewritten at some point to: Content-Type: text/plain; charset="us-ascii" ... i.e. KMail would add double-quotes to the charset value, probably in an attempt to "normalize" headers. Alas, this has the immediate side-effect of breaking the GPG signature; KMail then displays the mail content within a red frame titled "Invalid signature" while the original message and signature were perfectly matching. Reproducible: Always Steps to Reproduce: 1. Get sent a signed mail with a quote-less Content-Type header in the signed part 2. Receive that mail with KMail (tested with the POPS protocol) Actual Results: * Double quotes were added to the Content-Type header in the signed part * The signature is considered invalid Expected Results: * The mail should be left as untouched as possible * The signature should be considered valid
Verified here. Received message shows as invalid signature in kmail. When saving the message locally, extracting message text and signature and removing the quotes and newline at the end of the email text gpg --verify sig text works.
Forgot to say: version 4.11.00
I can confirm that : -Content-Type: text/plain; charset=iso-8859-1 +Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On a mail I just received.
I just received a Mail where KMail changed Content-Type: multipart/signed; boundary="J/dobhs11T7y2rNN"; micalg=pgp-sha1; protocol="application/pgp-signature" to Content-Type: multipart/signed; boundary="J/dobhs11T7y2rNN"; micalg="pgp-sha1"; protocol="application/pgp-signature" resulting in an invalid signature.
I can confirm this bug on master branch
Created attachment 82696 [details] An mail gnerated by mutt without any errors
First we have to make sure that we are talking about the same signing protocol :) I only tested now OpenPGP Mime: I read the RFC 3156 "5. OpenPGP signed data" and it is totaly ok, that the signature get broken, if the header get changed, 'cause the header is part of the signed content. I can't generate any mail, that is shown broken, when i generate it with mutt (without manually modifing the header). Please test the attached mail generated by mutt. Can you please generate&upload an mail with broken signature ( use save from kmail) and the original mail?
It's about SMIME not GPG, but I think it's same problem. I'm having same problems with SMIME signed emails from my bank. Saving message and trying to verify using: openssl smime -verify -in filename.txt fails. When I try to verify the save the same message saved from gmail it is successful. The difference that seems significant in this case are extra newlines added before part separators. Removing the newlines makes the message pass the verification.
Created attachment 85521 [details] Example mail (from bank) as saved from gmail I've found one I can share. This message passes verification: > openssl smime -verify -in alior-gm.txt ..... Verification successful
Created attachment 85522 [details] Example mail as saved from kmail Saved using save as from kmail - this one fails verification: openssl smime -verify -in alior-km.mbox (...) Verification failure
The requested information was provided long ago, back to confirmed.
Sorry, i forgot about this issue.Unfortunatelly i'll get for both Verification failed, because the mail is too old : % openssl smime -verify -in alior-km.mbox Verification failure 139929104623248:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:319:Verify error:certificate has expired % openssl smime -verify -in alior-gm.mbox Verification failure 139695521343120:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:319:Verify error:certificate has expired maybe you can add a new one and/or test with the current version 4.14.X. because the adding newlines to the mail I have fixed for another bug, so maybe this one is solved in meanwhile too... (https://bugs.kde.org/331991).
Seems to work! When I save the email to file and try to verify it using openssl it validates. I still have some issue with kmail complaining about "Not enough information to check signature validity." but this seems to be unrelated to this particular bug, and possibly an issue with my system. Just in case I'll also attach a newer signed email.
Created attachment 96442 [details] Signed email example, saved by kmail 5.0.2
That's good to hear that the modifing mail issue is now solved. Maybe Andre can give the nessary information, why we still see: "Not enough information to check signature validity." I am not using smime a lot myself, that's why I'm not that familiar with the statuses from smime.
Created attachment 96444 [details] Valid signature of example mail The error message is indeed horrible. Afaik it's intended to mean "GnuPG does not know whether or not it should trust the certificate so "Not enough information"". You can get some more details from the Audit Log. My best bet would be though that you do not have the root certificate of the certificate chain for jp-bank.japanpost.jp marked as a trusted issuer. You can do that by adding the fingerprint to ~/.gnupg/trustlist.txt and restart the dirmngr service / gpgsm. In Kleopatra this certificate would be shown in Other Certificates. There you can also use "Trust root certificate" by right clicking the root certificate. It should then show up under Trusted certificates. Only messages that are signed by a certificate in the Trusted Certificates group show up as Green in KMail. Attached is a screenshot showing that KMail generally can verify that mail correctly. I think this bug can be closed. Maybe a different bug for Kleopatra / S/MIME usability ;-)
Good tip, indeed kmail misses the root cert. I'll try to fix it once I find some more spare time. Anyway, I agree, this is different story, and this bug can be closed.
@Andre: thanks for clearification. @Michal: feel free to open a new bug about the bad UX.