Bug 427091 - Kmail gpg bad signature if From header contains non-ascii characters
Summary: Kmail gpg bad signature if From header contains non-ascii characters
Status: RESOLVED FIXED
Alias: None
Product: kmail2
Classification: Applications
Component: crypto (show other bugs)
Version: 5.15.1
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 432040 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-09-29 00:20 UTC by André M
Modified: 2021-02-22 00:21 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.16.1


Attachments
Disable protected headers in messagelib (489 bytes, patch)
2020-12-08 23:30 UTC, Lukáš Turek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description André M 2020-09-29 00:20:00 UTC
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
Comment 1 André M 2020-09-29 00:23:25 UTC
"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).
Comment 2 Lukáš Turek 2020-12-07 17:25:37 UTC
I can confirm the bug, it's a regression after update from 20.04.3 to 20.08.3.
Comment 3 Timo Weingärtner 2020-12-08 12:23:29 UTC
In my config 8859-1 is not in the list, but kmail changes encondig to it anyways.
Comment 4 Lukáš Turek 2020-12-08 23:30:18 UTC
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.
Comment 5 Ingo Klöcker 2020-12-20 17:30:39 UTC
I'm experiencing the same problem because my name also contains a non-ASCII character.
Comment 6 Ingo Klöcker 2020-12-20 17:52:23 UTC
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.
Comment 7 Bug Janitor Service 2020-12-21 16:01:06 UTC
A possibly relevant merge request was started @ https://invent.kde.org/pim/messagelib/-/merge_requests/21
Comment 8 Sandro Knauß 2020-12-21 17:08:22 UTC
(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
Comment 9 Sandro Knauß 2021-01-05 18:00:40 UTC
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
Comment 10 Sandro Knauß 2021-02-01 19:27:48 UTC
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
Comment 11 Sandro Knauß 2021-02-22 00:21:23 UTC
*** Bug 432040 has been marked as a duplicate of this bug. ***