Failing pim/messagelib tests for text/pgp data

--nextPart2216541.gBsaNRSFpC
Content-Type: multipart/mixed; boundary="nextPart2162354.BFZWjSADLM";
 protected-headers="v1"
Content-Transfer-Encoding: 7Bit
From: Ingo =?UTF-8?B?S2zDtmNrZXI=?= <[email protected]>
To: [email protected]
Subject: Failing pim/messagelib tests for text/pgp data
Date: Sun, 17 Aug 2025 18:06:00 +0200
Message-ID: <3211802.KVeVyVuyWN@daneel>
MIME-Version: 1.0

This is a multi-part message in MIME format.

--nextPart2162354.BFZWjSADLM
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"

Hi,

I know now why mimetreeparser-basicobjecttreeparsertest fails sometimes. I 
don't understand why it doesn't always fail.

I had a look at ObjectTreeParserTest::testOpenPGPEncryptedOverrideEncoding(). 
This test uses the attached test message. It's a message with a "text/PGP" 
attachment without any other content. The idea is that it's rendered like a 
"text/plain" message with inline encrypted text.

The problem is that (because of content-type "text/*") the message is decoded 
as if the base64-encoded data was text. This happens in 
KMime::ContentPrivate::decodeText(). The problem is that this method ensures 
that the decoded "text" ends with an LF character. In case of a "proper" 
"text/PGP" attachment the base64-encoded data is binary OpenPGP data. The 
method appends an LF to this binary OpenPGP data.

This additional LF causes gpg to error out (with a NO_DATA error) when 
decrypting the message. To stderr it logs something like "invalid packet 
type".

For unknown reasons (probably timing related) the test often passes. Maybe 
because gpg reports "DECRYPTION_OKAY" along with the decrypted text before the 
invalid byte at the end of the data is parsed. If full gpgme debug logging to 
a file is enabled then the test fails almost always (I don't remember a single 
pass of the test in this case; I'd love to compare the logs a passing test). 
I'm using the following command line for running the test:
```
GPGME_DEBUG=8:$(pwd)/gpgme-$(date +"%Y-%m-%d-%H%M%S").log \
bin/basicobjecttreeparsertest.shell testOpenPGPEncryptedOverrideEncoding
```

A possible fix would be to special-case the content-type "text/pgp" in 
KMime::ContentType::isText() so that we return false in this case. Since 
"text/pgp" is binary OpenPGP data (maybe it could also be ASCII armored 
OpenPGP data but that's irrelevant) this change wouldn't be wrong. Except that 
it feels wrong to special-case "text/pgp", or, more precisely, it feels wrong 
that something like "text/pgp" should exist if the data isn't actually text 
but a binary blob of encrypted text.

I tried to find out where "text/pgp" comes from. It's not registered by IANA 
and DuckDuckGo didn't find any hits for "text/pgp" (if quoted; without quotes 
it show plenty PGP-related hits) while I get plenty of hits for "application/
pgp". messagelib contains three test messages with "text/pgp" attachments. All 
have "User-Agent: Roundcube Webmail/1.1.9". I tried to find references to 
"text/pgp" in the source code of roundcubemail (master and release-1.1 branch) 
and failed.

@Sandro: Do you know of any clients that create such messages? I guess all 
sensible clients produce proper OpenPGP/MIME messages nowadays.

Regards,
Ingo

--nextPart2162354.BFZWjSADLM
Content-Disposition: attachment;
 filename="openpgp-encrypted-attachment-iso-8859-15-encoded.mbox"
Content-Transfer-Encoding: 7Bit
Content-Type: application/mbox;
 name="openpgp-encrypted-attachment-iso-8859-15-encoded.mbox"

From [email protected] Tue Oct 03 10:05:19 2017
Return-Path: <[email protected]>
To: [email protected]
Subject: only an encrypted attachment with iso-8859-15 encoding
X-PHP-Originating-Script: 1008:rcube.php
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="=_XXXXXXXXXXXXXX"
Date: Tue, 03 Oct 2017 12:13:14 +0000
From: [email protected]
Message-ID: <[email protected]>
X-Sender: [email protected]
User-Agent: Roundcube Webmail/1.1.9

--=_XXXXXXXXXXXXXX
Content-Transfer-Encoding: base64
Content-Type: text/PGP
Content-Disposition: attachment;
 filename=encrypted.txt.pgp

hIwDGJlthTT7oq0BA/9OUBr6T4JJ6wbsc93YPu3xHJXPifSGmavEDBCFJ2fqt5/j
HcciOM8N7l0kBkjWVRXKU4ddRZMRbkEMpNViIt7yt1JSoeQQkXU7bwBNSOvnXYXE
rkL6BI7vaSJJEx/Jkv6hgoT4/NJ6kLA07f6fV40ew5Skxdjswx/ln/vXscA0EdKd
AUyFfmHmKkoywoqE0012A00uY3RMPiROf0Z5Bm0mjuNg5qYn5Far4YdPkeT9r8lF
1azGqpG2/SEsNV8jFyLwzWfbP2fxb/L1QNiU4q7Qyck2jKFluaZASipph6TQunMf
RY/lB3ghKCsrLm4eNzv3kKpMjxAxx6uXAAI4QUtcu31Y41e9vfYrPuVwHHK1m76S
qge1wxs4YbLjvatiiA==
=zH6Q

--=_XXXXXXXXXXXXXX--

--nextPart2162354.BFZWjSADLM--

--nextPart2216541.gBsaNRSFpC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iJEEABYKADkWIQTbjgIOMowwlCBgvyGxb1mVFkdKugUCaKH96BsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMSwyLDIACgkQsW9ZlRZHSroc6gD9FmfisshmWBpLroImJw35
76BXg2uWfIg1pRKJ/QLg7YUBAKyrC2xSyquXdwvlxmL+W7m8rA2GXbln7/t/QwpK
YRcO
=VUID
-----END PGP SIGNATURE-----

--nextPart2216541.gBsaNRSFpC--