Failing pim/messagelib tests for text/pgp data

[Ingo Klöcker]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-encrypted-attachment-iso-8859-15-encoded.mbox
Type: application/mbox
Size: 1045 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20250817/d9392193/attachment.mbox>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20250817/d9392193/attachment.sig>