SUMMARY I was getting GPG Bad signature on my own sent messages (to my self, as a test), and also upon saving with Sign on save option set. After a lot of debugging, I could identify that if (at least) the From field contains non-ascii characters (in my case, my name), Kmail did change the field encoding **after** it got signed, giving that error on any client which would try to verify the OpenPGP/MIME attached signature. From setting some debug options in GnuPG dialog, and created "dbgmd-00001.sign" and "dbgmd-00001.verify" files, I can see they differ in the former containing "From: =?UTF-8?B?QW5kcsOp?= Vitor de Lima Matos <andre.vmatos@gmail.com>" header, while the final mail body and verify header got changed to "From: =?ISO-8859-1?Q?Andr=E9?= Vitor de Lima Matos <andre.vmatos@gmail.com>" (the issue here then is on the "é" character). The issue doesn't happen if e.g. Subject header contains the non-ascii character, with both signed and final versions ending in the UTF-8 version. Workaround for now is to remove non-ascii characters from my identity's name. Not sure if it matters, but my Composer's charset list is set to [utf-8, iso-8859-1, us-ascii] STEPS TO REPRODUCE 1. Have given set of charset in that order in config 2. Create a new mail and set some non-ascii character in From field 3. Save/sign and/or send the email 4. See Bad signature error. OBSERVED RESULT Final email body (used to verify signature) re-encodes the From field AFTER it got signed, making signature verification fail. EXPECTED RESULT Any [re-]encoding (if needed) should be done BEFORE signing, and the body/headers should NEVER be touched after gpg signing was performed. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux testing (available in About System) KDE Plasma Version: 5.19.90 KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1 ADDITIONAL INFORMATION
"To" field suffers of the same problem, making it very hard to write to contacts containing non-ascii characters in name (need to edit and normalize it before signing/sending mail).
I can confirm the bug, it's a regression after update from 20.04.3 to 20.08.3.
In my config 8859-1 is not in the list, but kmail changes encondig to it anyways.
Created attachment 133939 [details] Disable protected headers in messagelib I found a workaround: when protected headers are disabled in messagelib, To: and From: headers don't affect the signature, so it validates OK.
I'm experiencing the same problem because my name also contains a non-ASCII character.
By the way, it seems that encrypted+signed messages are not affected by this problem. On the other hand, looking at the decrypted MIME tree of such a message it makes me wonder whether protected headers is actually correctly implemented for encrypted+signed messages. To me it seems as if the "protected headers" are not part of the signed message part but of the enclosing multipart/signed message part which means that they are not really protected by the signature. Ironically, this implementation bug prevents the signatures of encrypted+signed messages to be broken by the protected headers feature.
A possibly relevant merge request was started @ https://invent.kde.org/pim/messagelib/-/merge_requests/21
(In reply to Ingo Klöcker from comment #6) > By the way, it seems that encrypted+signed messages are not affected by this > problem. On the other hand, looking at the decrypted MIME tree of such a > message it makes me wonder whether protected headers is actually correctly > implemented for encrypted+signed messages. To me it seems as if the > "protected headers" are not part of the signed message part but of the > enclosing multipart/signed message part which means that they are not really > protected by the signature. Ironically, this implementation bug prevents the > signatures of encrypted+signed messages to be broken by the protected > headers feature. It is correct, that the "protected headers" are not signed with encrypted+signed. As it does not use SingEncryptJob but assembles the mail by hand in composerjob, but this is a different issue. But anyways as the content is encrypted there is only a binary blob, that cannot been modified afterwards and this prevents any external modification and a valid signature. The ProtectedHeadersJob was only referencing all the headers, to save some memory and I thought, that the headers are finalized already. This assumption turns out to be wrong, so I copy now all headers see the merge request: https://invent.kde.org/pim/messagelib/-/merge_requests/21
Git commit 3a7114399b105cbe159355f600b9d3e08ec10fcb by Sandro Knauß. Committed on 05/01/2021 at 17:50. Pushed by knauss into branch 'release/20.12'. Fix[messagecomposer]: Do copy all mail headers instad of reference them. When dealing with encryption and protected headers it is enough to reference the headers in the messagepart, as the result is encrypted directly. This is different for Sign only and there may be jobs after signing that are changing the mail headers, so we need to copy all headers into the encapsulated part instead of referencing them. FIXED-IN: 5.16.1 M +55 -0 messagecomposer/autotests/signjobtest.cpp M +2 -0 messagecomposer/autotests/signjobtest.h M +5 -6 messagecomposer/src/job/protectedheadersjob.cpp https://invent.kde.org/pim/messagelib/commit/3a7114399b105cbe159355f600b9d3e08ec10fcb
Git commit c57eb4d95e67c8b28305c1c0c9e29179530fcd1d by Sandro Knauß. Committed on 01/02/2021 at 19:19. Pushed by knauss into branch 'release/20.08'. Fix[messagecomposer]: Do copy all mail headers instad of reference them. When dealing with encryption and protected headers it is enough to reference the headers in the messagepart, as the result is encrypted directly. This is different for Sign only and there may be jobs after signing that are changing the mail headers, so we need to copy all headers into the encapsulated part instead of referencing them. FIXED-IN: 5.16.1 M +55 -0 messagecomposer/autotests/signjobtest.cpp M +2 -0 messagecomposer/autotests/signjobtest.h M +5 -6 messagecomposer/src/job/protectedheaders.cpp https://invent.kde.org/pim/messagelib/commit/c57eb4d95e67c8b28305c1c0c9e29179530fcd1d
*** Bug 432040 has been marked as a duplicate of this bug. ***