Bug 439958 - X-Face can break cryptographic signatures
Summary: X-Face can break cryptographic signatures
Status: RESOLVED FIXED
Alias: None
Product: kmail2
Classification: Applications
Component: crypto (show other bugs)
Version: 5.16.3
Platform: Gentoo Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-16 21:15 UTC by David C. Bryant
Modified: 2022-02-24 14:47 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 21.12.3


Attachments
Raw email message sent from Gentoo, KMail 5.16.3 (7.94 KB, application/mbox)
2021-07-16 22:00 UTC, David C. Bryant
Details
Raw Email message from KDE Neon (6.66 KB, application/mbox)
2021-07-16 22:02 UTC, David C. Bryant
Details
Message composed under openSUSE Tumbleweeed (KMail 5.17.3) (6.66 KB, application/mbox)
2021-07-16 22:05 UTC, David C. Bryant
Details
Raw email message composed under openSUSE LEAP 15.3 (6.51 KB, application/mbox)
2021-07-16 22:07 UTC, David C. Bryant
Details
Raw email message composed under Manjaro (KMail 5.17.3). (7.61 KB, application/mbox)
2021-07-16 22:08 UTC, David C. Bryant
Details
Raw email composed under Tumbleweed (KMail 5.17.3). (1.91 KB, application/mbox)
2021-07-16 22:15 UTC, David C. Bryant
Details
Screenshot of message composed under Gentoo, KMail 5.16.3 (82.50 KB, image/png)
2021-07-17 18:05 UTC, David C. Bryant
Details
Test message composed under Gentoo, KMail 5.16.3. The signature is OK when the message is encrypted. (122.50 KB, image/png)
2021-07-17 18:09 UTC, David C. Bryant
Details
Image from Artix Linux, 07/28, in the morning (51.70 KB, image/png)
2021-07-29 16:33 UTC, David C. Bryant
Details
Image from Artix Linux, 07/28, in theafternoon (60.43 KB, image/png)
2021-07-29 16:34 UTC, David C. Bryant
Details
Screenshot -- signature works OK with X-Face disabled (105.68 KB, image/png)
2021-09-27 13:15 UTC, David C. Bryant
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David C. Bryant 2021-07-16 21:15:34 UTC
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
Comment 1 David C. Bryant 2021-07-16 22:00:14 UTC
Created attachment 140123 [details]
Raw email message sent from Gentoo, KMail 5.16.3
Comment 2 David C. Bryant 2021-07-16 22:02:08 UTC
Created attachment 140124 [details]
Raw Email message from KDE Neon
Comment 3 David C. Bryant 2021-07-16 22:05:09 UTC
Created attachment 140125 [details]
Message composed under openSUSE Tumbleweeed (KMail 5.17.3)
Comment 4 David C. Bryant 2021-07-16 22:07:08 UTC
Created attachment 140126 [details]
Raw email message composed under openSUSE LEAP 15.3
Comment 5 David C. Bryant 2021-07-16 22:08:14 UTC
Created attachment 140127 [details]
Raw email message composed under Manjaro (KMail 5.17.3).
Comment 6 David C. Bryant 2021-07-16 22:15:32 UTC
Created attachment 140128 [details]
Raw email  composed under Tumbleweed (KMail 5.17.3).
Comment 7 David C. Bryant 2021-07-17 18:05:18 UTC
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.
Comment 8 David C. Bryant 2021-07-17 18:09:47 UTC
Created attachment 140145 [details]
Test message composed under Gentoo, KMail 5.16.3.  The signature is OK when the message is encrypted.
Comment 9 David C. Bryant 2021-07-29 16:33:16 UTC
Created attachment 140391 [details]
Image from Artix Linux, 07/28, in the morning
Comment 10 David C. Bryant 2021-07-29 16:34:27 UTC
Created attachment 140392 [details]
Image from Artix Linux, 07/28, in theafternoon
Comment 11 David C. Bryant 2021-07-29 16:58:36 UTC
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).
Comment 12 Ingo Klöcker 2021-09-06 16:24:40 UTC
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.
Comment 13 Sandro Knauß 2021-09-27 10:10:19 UTC
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).
Comment 14 David C. Bryant 2021-09-27 13:13:52 UTC
(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.
Comment 15 David C. Bryant 2021-09-27 13:15:30 UTC
Created attachment 141949 [details]
Screenshot -- signature works OK with X-Face disabled
Comment 16 Sandro Knauß 2021-09-27 14:09:24 UTC
(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
Comment 17 Bug Janitor Service 2021-12-30 15:45:34 UTC
A possibly relevant merge request was started @ https://invent.kde.org/pim/messagelib/-/merge_requests/74
Comment 18 Sandro Knauß 2022-02-24 14:47:32 UTC
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