SUMMARY KMail composer creates invalid crypto signature. STEPS TO REPRODUCE 1. Compose a new message, select "Sign Message" but not "Encrypt Message" 2. Send the message, or save it as a draft. OBSERVED RESULT Signature invalid. See attachments. EXPECTED RESULT The signature should be valid. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.21.5 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION I first saw this bug in November, 2020. I asked about in in gitlab, and was assured it had been fixed. But it keeps popping up all over the place. I have several different Linux platforms installed on my hard drive. Here's a list. openSUSE LEAP 15.3 (KMail 5.14.2) -- Signature works correctly. openSUSE Tumbleweed (KMail 5.17.3?) -- Signature is broken. KDE Neon 5.22.3 (KMail 5.17.3) -- Signature is broken. Manjaro (Plasma 5.22.3, Frameworks 5.84.0, KMail 5.17.3) -- Signature works OK. So on the more or less "current" distros, Manjaro Linux works correctly. I have also tested this pretty extensively using "kdesrc-build" and KDE sources. It works right with Manjaro Linux, but fails on Gentoo / Neon / Tumbleweeed (openSUSE LEAP won't play nice with kdesrc-build; Frameworks are too old). Also reported to Gentoo team: https://bugs.gentoo.org/800689
Created attachment 140123 [details] Raw email message sent from Gentoo, KMail 5.16.3
Created attachment 140124 [details] Raw Email message from KDE Neon
Created attachment 140125 [details] Message composed under openSUSE Tumbleweeed (KMail 5.17.3)
Created attachment 140126 [details] Raw email message composed under openSUSE LEAP 15.3
Created attachment 140127 [details] Raw email message composed under Manjaro (KMail 5.17.3).
Created attachment 140128 [details] Raw email composed under Tumbleweed (KMail 5.17.3).
Created attachment 140143 [details] Screenshot of message composed under Gentoo, KMail 5.16.3 When the message is signed, but not encrypted, the crypto signature is malformed.
Created attachment 140145 [details] Test message composed under Gentoo, KMail 5.16.3. The signature is OK when the message is encrypted.
Created attachment 140391 [details] Image from Artix Linux, 07/28, in the morning
Created attachment 140392 [details] Image from Artix Linux, 07/28, in theafternoon
I installed Artix Linux on July 25. At first the signati=ures worked OK in KMail. Yesterday the signature algorithm stopped working. See my post in the Artix forum https://forum.artixlinux.org/index.php/topic,2892.0.html for additional details. KMail is version 5.17.3. Here are details from an Artix mirror. kmail-21.04.3-1-x86_64.pkg.tar.zst 08-Jul-2021 19:04 6389027 Looks very much like an ArchLinux mirror: kmail-21.04.3-1-x86_64.pkg.tar.zst 2021-07-08 07:21 6.1M I have attached screenshots of two emails composed in Artix on July 28th, one in the morning (good signature) and one in the afternoon (bad signature).
I suspect the problem is caused by the protected headers feature in combination with the X-Face header. All examples with good signature were either made with a version of KMail that did not yet have the protected headers feature (openSUSE LEAP 15.3) or do not include an X-Face header (Manjaro, Artix in the morning). All other examples have a copy of the X-Face header in the signed message part.
I can confirm it, but it is not reproducible with every gpg key, what is quite strange. What I checked is to create a draft with X-Face enabled. For one gnupg key the signatures keep fine. When I select another key, the signature is broken with the same X-Face. (I actually modified the identity and change the gnupg key and the matching email address). At least, if those mails get send, the signautre would get broken in any case, as the X-Face line is too long for most mail servers, so they would break the line and this will break the signature in always. @David: can you check, if you get proper signatures, if you disable the picture (X-Face)? (Picture tab of the Identity).
(In reply to Sandro Knauß from comment #13) > I can confirm it [snip ...] > > @David: can you check, if you get proper signatures, if you disable the > picture (X-Face)? (Picture tab of the Identity). Yes, Sandro, signatures work fine with X-Face disabled. See the screenshot I'm adding as an attachment to this bug report today. I am using the same picture as was in the X-Face header as my gravatar (see discussion below). So the message appears the same (to me) both with and without embedded X-Face headers (except that X-Face breaks the crypto signature). A friend referred me to this web page: https://datatracker.ietf.org/doc/html/draft-autocrypt-lamps-protected-headers-02 and raised the question "should the X-Face header be a protected header?" I'm not real sure of the answer. Personally, I don't care if somebody views the wrong picture in a signed message I send. Integrity of the text message is all I really care about. Others might feel differently, though. One other thing. The field used to display the "X-Face" picture is also used to display "gravatars" kept on file in KAddressbook. So people can (in effect) attach pictures to their messages without using "X-Face" (with the recipient's assistance). One can even configure KMail itself to search for gravatars on the internet (Configure KMail --> Plugins --> Gravatar Config). So "X-Face" is becoming redundant. Just a thought.
Created attachment 141949 [details] Screenshot -- signature works OK with X-Face disabled
(In reply to David C. Bryant from comment #14) > (In reply to Sandro Knauß from comment #13) > > I can confirm it [snip ...] > > > > @David: can you check, if you get proper signatures, if you disable the > > picture (X-Face)? (Picture tab of the Identity). > > Yes, Sandro, signatures work fine with X-Face disabled. See the screenshot > I'm adding as an attachment to this bug report today. I am using the same > picture as was in the X-Face header as my gravatar (see discussion below). > So the message appears the same (to me) both with and without embedded > X-Face headers (except that X-Face breaks the crypto signature). Okay, than I have to look into why X-Face header sometimes breaks the signature. It needs to be any modification after the signature is done. The X-Face header have multiple lines in autosave files. So I expect, that somehow the newlines gets stripped out after the signature is created. > A friend referred me to this web page: > https://datatracker.ietf.org/doc/html/draft-autocrypt-lamps-protected- > headers-02 and raised the question "should the X-Face header be a protected > header?" I'm not real sure of the answer. Personally, I don't care if > somebody views the wrong picture in a signed message I send. Integrity of > the text message is all I really care about. Others might feel differently, > though. Well the X-Face header is for sure a non-structural header and the RFC tells us to copy ALL non-structural headers, that are known when composing the mail. https://datatracker.ietf.org/doc/html/draft-autocrypt-lamps-protected-headers-02#section-4.1
A possibly relevant merge request was started @ https://invent.kde.org/pim/messagelib/-/merge_requests/74
Git commit b23d11d27d8619715a2fb3fa5a290e11cb5a027b by Sandro Knauß. Committed on 24/02/2022 at 14:13. Pushed by knauss into branch 'release/21.12'. [messagecomposer] Do not sign long headers. As KMime sometimes strips newlines from headers, this makes signatures break, if the signed content includes those headers. In order to have a fast fix, do not add long headers to the signature part. FIXED-IN: 21.12.3 M +51 -0 messagecomposer/autotests/signjobtest.cpp M +1 -0 messagecomposer/autotests/signjobtest.h M +8 -0 messagecomposer/src/job/protectedheadersjob.cpp https://invent.kde.org/pim/messagelib/commit/b23d11d27d8619715a2fb3fa5a290e11cb5a027b