GNOME Bugzilla – Bug 719877
KMail GPG signatures sometimes recognized as invalid
Last modified: 2017-01-04 11:46:27 UTC
Created attachment 263558 [details] Signed email Evolution 3.8.x shows a valid GPG signature as invalid. This particular email was produced with KMail 4.11.2. The signature is correctly recognized by both KMail and Thunderbird 24 with enigmail. Sorry, I can't test with newer Evolution. Would be glad if somebody else can do it (I've attached the email, so it should be fairly trivial).
The missing blank line between the message body and signature seems to be what's tripping up the verification. I'm not sure if it means the email is malformed, but I'll try and work around it anyway. ... GPG key: https://stikonas.eu/stikonas.asc Fingerprint: 1EE5 A320 5904 BAA2 B88C 0A9D 24FD 3194 0095 C0E1 --nextPart1806434.j9iqmj4k1b ...
Adding a blank line to my signature fixed it. Thanks! There is another problem (signature is broken if email is sent using 7-bit encoding instead of quoted-printable) but then Enigmail shows broken signature too, so maybe that's KMail's problem.
Note to self and anyone else who looks into this: The problem is that CamelMimeFilterCanon depends on input lines ending with a newline, otherwise it considers the line unfinished and withholds it from the output results, expecting the next filter() or complete() call to contain the rest of the line. However, CamelStreamFilter's write() method lies and always returns number of bytes written equal to requested, even if the filter is withholding some data. That means the data withheld is lost, even if the caller tries to correctly handle short writes. In the test mail above the last line ("Fingerprint: ...") got dropped because it doesn't end with a newline, and so GPG was verifying the signature against a truncated message. Hence the failure. But I consider the test mail to be malformed by KMail, and I don't know how to fix CamelStreamFilter and/or CamelMimeFilterCanon without breaking legitimate cases. The reporter has found a workaround, so I'm going to move on. Long-term plan is to port all the filter classes to the GConverter interface, which has easier semantics than CamelMimeFilter. So maybe that will fix it.
Just to mention, the attached message shows a valid signature in 3.23.3 (development version, but should be pretty much the same as 3.22.3 and even 3.20.x, I guess), but there is still some issue with KMail generated messages. That's when the KMail chooses a 7bit encoding, instead of quoted-printable and the message contains a space at the end of any line, like in the signature separator, which is "-- \n". The camel filter removes that ending space when passing it to the gpg, which causes the signature to be recognized as invalid.
I see that the change to strip trailing white-spaces had been added for bug #571046, where a downstream bug report [1] nicely summarizes why it does so. From that I'd say that KMail does things wrong. Even I could try to verify the message signature twice, once with striping trailing white-spaces and if it fails then without striping them, but I'm afraid it'll be just a workaround for KMail-generated messages, instead of fixing the root cause of it, which is in the KMail in this case. They should choose a quoted-printable encoding of the text, if it contains any trailing white-spaces, instead of the 7bit encoding. I'm closing this as fixed, because the initial issue is fixed. [1] https://bugzilla.redhat.com/show_bug.cgi?id=481408#c7