Email text disappears with PGP signature

Bug Reports
#1

REPRODUCIBILITY: 100%
BUILD ID: 3.3.0.16
HARDWARE: Xperia X
UI LANGUAGE: German
REGRESSION: No

DESCRIPTION:

Enabling PGP signatures for an account makes email content disappear and only the signature block show up instead.

In the inbox of the addressee the message looks like this:

iQIVAwUBX0UBmVMTC9O9P […]
======== SIGNATURE BLOCK REMOVED ====
===========[…]========================
-----END PGP SIGNATURE-----

–[)}<qmf:1550879736twUS21C2j3w4+GDoWIx/fQ==)}<]–

But the original text I typed is

Test message with PGP signature
Confustion ondeck some ropes are amiss.

In some mail clients (Outlook?) this seems to lead to an empty message altogether, not even the signature block is displayed.

The copy I have in my sent folder on the Phone looks fine.
Looking at the sent email in Thunderbird though shows the same signature block as appears on the recipients side.

PRECONDITIONS:

PGP key pair is available (imported in Settings) and signing key selected for signatures in email account.

STEPS TO REPRODUCE:

  1. Create a new message
  2. Enable PGP signature
  3. Type some Text
  4. Send

EXPECTED RESULT:

Signature block is attached after message content

ACTUAL RESULT:

No message content, signature block only

ADDITIONAL INFORMATION:

Source of the recieved email (redacted):

Return-Path: <ADDRESS_REMOVED>
Delivered-To: ADDRESS_REMOVED
Received: from proxy02.mailserver_removed.name ([127.0.0.1])
	by dovecot04.mailserver_removed (Dovecot) with LMTP id nN7RCI0BRV+DBAEAvlP5og
	for <ADDRESS_REMOVED>; Tue, 25 Aug 2020 14:18:36 +0200
Received: from proxy02.mailserver_removed ([127.0.0.1])
	by proxy02.mailserver_removed.name (Dovecot) with LMTP id 0i4fGw7/RF+MrAAAGFAyLg
	; Tue, 25 Aug 2020 14:18:36 +0200
Received: from mailin05.mailserver_removed (unknown [IP_removed])
	by proxy02.mailserver_removed (Postfix) with ESMTPS id 4BbShD5D2Mz11fH
	for <ADDRESS_REMOVED>; Tue, 25 Aug 2020 14:18:36 +0200 (CEST)
Received: from mx03.mailserver_removed (mailin05.mailserver_removed [127.0.0.1])
	by mailin05.mailserver_removed (Postfix) with ESMTPS id A601520E39
	for <ADDRESS_REMOVED>; Tue, 25 Aug 2020 14:18:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at mailserver_removed
Authentication-Results: mailin05.mailserver_removed (amavisd-new);
	dkim=pass (2048-bit key) header.d=mailserver_removed
Received: from mout01.mailserver_removed (unknown [IP_removed])
	by mx03.mailserver_removed (Postfix) with ESMTPS id 4BbShD2vbWz10vX
	for <ADDRESS_REMOVED>; Tue, 25 Aug 2020 14:18:36 +0200 (CEST)
Authentication-Results: mx03.mailserver_removed; dmarc=pass (p=none dis=none) header.from=mailserver_removed
Authentication-Results: mx03.mailserver_removed;
	dkim=pass (2048-bit key) header.d=mailserver_removed header.i=@mailserver_removed header.b=fg3HyHlv;
	dkim-atps=neutral
Received: from submission (mailserver_removed [IP_removed]) 
	by mout01.mailserver_removed (Postfix) with ESMTPS id 3538D16005F
	for <ADDRESS_REMOVED>; Tue, 25 Aug 2020 14:18:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailserver_removed; s=2017;
	t=1598357916; bh=5wBTOBRr4KCwVuyOigPQDcSedhfL4+FS1HfUwautdvo=;
	h=To:From:Subject:Date:From;
	b=fg3HyHlvDsd2Sq318oex+bPrDIQ14VSup/hypgktJd2T8EaPJRqPbnQ0+EaHRBqkI
	 yeC8zhPsbG7Abe5lFcE5SvgXHxgJxlUHqR8y7ziL1VM/oUx9LIUFqMMgvN/PhBK8wq
	 D/0YLwCg58eyfc7/AUju4VqQCbwEhJCPvtW62F4xzBe9ZsXc4lH0Itw0kADGiHNUy3
	 ZAc3sKvLdJUv8kVlmj5skkLhIf4wzqhmy+hrWztIC5kOYoYfKYj95gQx7t3X5uODIf
	 NmV5zfw4IT2X45n8XwtdYVq/e7vDKq6oO5yBCz0EAskbj/NS3auBdZeop0lALD6ArZ
	 MGMrPhXSALP6g==
Received: from customer (localhost [127.0.0.1])
	by submission (mailserver_removed) with ESMTPSA id 4BbShC5PCWz6tmc
	for <ADDRESS_REMOVED>; Tue, 25 Aug 2020 14:18:35 +0200 (CEST)
X-Priority: 3
To: ADDRESS_REMOVED
From: <ADDRESS_REMOVED>
Subject: SFOS PGP signage test
Content-Type: multipart/signed; charset=utf-8; micalg=pgp-sha1;
 protocol=application/pgp-signature;
 boundary="[)}<qmf:1550879736twUS21C2j3w4+GDoWIx/fQ==)}<]"
Date: Tue, 25 Aug 2020 12:18:32 +0000
Message-ID: <koegxu.qfmcuz.2xnt17-qmf@submission01.mailserver_removed>
MIME-Version: 1.0

This is a multipart message in Mime 1.0 format

--[)}<qmf:1550879736twUS21C2j3w4+GDoWIx/fQ==)}<]
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

VGVzdCBtZXNzYWdlIHdpdGggUEdQIHNpZ25hdHVyZS4NCkNvbmZ1c2lvbiBvbmRlY2sgc29tZSBy
b3BlcyBhcmUgYW1pc3MuIA==
--[)}<qmf:1550879736twUS21C2j3w4+GDoWIx/fQ==)}<]
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)

iQIVAwUBX0UBmVMTC9O9P [...]  
======== SIGNATURE BLOCK REMOVED ====
===========[...]=====================

--[)}<qmf:1550879736twUS21C2j3w4+GDoWIx/fQ==)}<]--
3 Likes
#2

Thanks for the report, I’ll give a look next week (since I wrote the code for it…).

2 Likes
#3

Let me know if you need any logs or other debug info

#4

I don’t know, I’ll see next week when I investigate. I’m sorry I don’t have time during this end of week… I’m wondering if I’m not missing a crriage return before the second boundary. I’ve extensively tested with my mailer (Claw-mail) but not much with others. Maybe Claw-mail was more easy with faulty emails…

3 Likes
#5

Relax. A weekend should be a weekend once in a while, too :wink:

Should you need any testing once you have time to look at it, just say so

3 Likes
#6

I’ve investigated a bit this morning this issue. Reading the RFC 2046, it is stated that:

The CRLF preceding the boundary delimiter line is conceptually
attached to the boundary so that it is possible to have a part that
does not end with a CRLF (line break).

So my first guess about a line break missing before the signature part boundary is wrong.

After that, I tried to reproduce without any success : ( I don’t have Outlook, but I can use Outlook Web App from work. Sending a signed message from my phone to my work email address is properly displayed. Looking at the same mail from Thunderbird is working also, and from GMail also. Then, I copied the content you attached to your report and looked at it from Claw-mail with success. Redirecting this (so I should receive it as is) to my work email address also is working fine when viewed from OutlookWebApp.

I’m sadly a bit stuck now. I try to guess what could be wrong, but have no clue… I’m not using IMAP on my phone so a signed message is not copied to the sent folder and I cannot see it from outside the phone. I’ll set up an IMAP account on the phone so I can try to reproduce the failure you reported with Thunderbird from the sent folder.

2 Likes
#7

First of all: thanks for looking into this.

I can try to reproduce it using another client (Geary) as well as another address.
I don’t have Outlook either (fortunately!) and since the behaviour is the same for Thunderbird, I figure it’s probably not the client. What do you think?

Maybe it’s Enigmail eating up the text or even my mail provider (which supports PGP natively). I’ll investigate some more once I find the time.

#8

I can also try to reproduce it but I’m afraid I don’t really know which steps you took (where did you set what and which client (+version) did you use to create the mail)?

#9

I agree. With your report, I’m sure I’m doing something wrong when composing the email to be sent to the server, but I cannot figure out what…

Thanks, I guess the email pristine content you reported in the first post was coming from a Ctrl+U in Thunderbird where it’s not properly displayed ? If not, can you copy-paste the source code of the email in your sent folder in Thunderbird ? And from which client does this content you copy-pasted come from ? Maybe it could help to figure out what’s wrong…

#10

You need to have a pair of public / private PGP keys associated to your email address and to have installed the jolla-email-crypto-gnupg package from default Jolla repositories.

  • Copy the private one to the phone and import with gpg2.
  • In the setting UI, go to your email account page and scroll to the bottom, you should see that you can choose to sign your emails with your key.
  • Compose a new email from this account on device, it should ask you your PGP passphrase before sending the email.
  • View your sent email with another client and check that the text is properly displayed and that the signature is attached and possibly checked if your public PGP key is available to your client.

For me this procedure is working with my provider (Free in France) and the sent email is properly displayed and checked on various clients. For @rozgwi it’s not the case and the content of the signature is displayed instead of the mail content.

1 Like
#11

So it turns out it’s in fact Enigmail. As soon as I disable the add-on, the text appears.
Very curious . Maybe it’s related to the rewrite for the integration in the upcoming Thunderbird 70.

Anyways I’m sorry to have sent you on a wild-goose chase. Should’ve tried with disabled plugins first thing.

#12

That is weird. AFAIK they changed nothing in the last versions except for the migration stuff.

Thank you for the instructions @dcaliste I will try it once I have some spare time

#13

That’s how I understood it as well. Maybe there is an issue with signatures created on SFOS and Enigmail only is very strict about parsing it.

#14

Indeed. I will try to install enigmail plug-in for Thunderbird also and play a bit with it. Maybe it will raise something ; )

1 Like
#15

I found the culprit in the crafted email from SFOS, in the declaration of the multipart of the email, the protocol is not escaped within quotes. This is confusing EnigMail.

Current declaration:

 Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol=application/pgp-signature;
 boundary="[)}<qmf:753856716hcbg/62S7cmu4ngo9qvS1Q==)}<]"

Correct one:

 Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="[)}<qmf:753856716hcbg/62S7cmu4ngo9qvS1Q==)}<]"

Indeed the parameter protocol has a value with a tspecial character (here ‘/’) that impose to quote the value, as described in this RFC : https://tools.ietf.org/html/rfc2045#page-12

I’ll look now in QMF code where I’ve done the mistake and correct it.

5 Likes
#16

Here is the upstream patch for QMF : https://codereview.qt-project.org/c/qt-labs/messagingframework/+/312509

I’m waiting for review, if accepted, I’ll update the version in SailfishOS accordingly.

It seems that it’s an issue from QMF itself that for some reasons I don’t know about was not treating the ‘/’ character as a protected character in parameter value that requires quoting.

2 Likes
#17

Brilliant.Thanks a lot, Damien! (Ils te devraient payer :wink:)

1 Like
#18

The merge request will not be accepted upstream immediately, or at least, it is accepted but cannot pass the CI because now the CI is running with Qt6, and the project is not ready yet for Qt6. I’ve created merge requests to allow the migration and please the CI, but there are a lot and the review will take time, see https://codereview.qt-project.org/q/project:qt-labs%2Fmessagingframework+status:open

In between, I’ve proposed to simply apply the patch on the version in SailfishOS and @pvuorela accepted it last week. So it should be fine on device starting from the next version (>3.4.0).

3 Likes
#19

Is this bug responsible for emails that only contain:

-----BEGIN PGP MESSAGE-----

hF4DsMegv3dvesISAQdAKfZje7xA....

Displaying empty in the email app? The fix was accepted in 2021, but I guess only for Qt6? If the block displayed one could copy/paste it into something to decode, now pgp is completely broken it seems, so no patchmanagerial approach to detect a block and offer decrypt option can even work (unless there is some other intentional filter on pgp-encrypted contentType?)