[GNUPG:] PLAINTEXT 62 1655920831 error

[nello]

Hi team, I have an interesting one. 

I am using python-gnupg version 0.4.6 on a linux machine.

I have an encrypted file coming to my application which needs to be decrypted (I correctly own the private key and I am using the same key to correctly decrypt different files using the same setup).

Here's some informations about the file using linux 'file' command and 'pgpdump':

file test_file.csv.pgp

test_file.csv.pgp: data

pgpdump test_file.csv.pgp

New: Compressed Data Packet(tag 8)(4096 bytes) partial start

   Comp alg - ZIP <RFC1951>(comp 1)

New:    (3244 bytes) partial end

New: unknown(tag 41)(110 bytes)

New: Compressed Data Packet(tag 8)

   Comp alg - unknown(comp 78)

pgpdump: unknown compress algorithm.

gpg --list-packet test_file.csv.pgp

# off=0 ctb=c8 tag=8 hlen=2 plen=0 partial new-ctb

:compressed packet: algo=1

# off=3 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb

:literal data packet:

   mode b (62), created 1655920831, name="",

   raw data: unknown length

My application calls the decrypt_file() method from the python-gnupg library. I have either tested using the output parameter or directly using the result object. This error is currently returned in both cases:

[GNUPG:] PLAINTEXT 62 1655920831

this is the full log when I enable the verbosity on the GPG object:

gpg --status-fd 2 --no-tty --no-verbose --fixed-list-mode --batch --with-colons --homedir /Users/test/Desktop/test/.gnupg --no-default-keyring --keyring /Users/test/Desktop/test/.gnupg/pubring.gpg --secret-keyring /Users/test/Desktop/test/.gnupg/secring.gpg --passphrase-fd 0 --decrypt --yes --output /Users/test/Desktop/test/test9yetqku/testnp2n7cfq

[GNUPG:] PLAINTEXT 62 1655920831

The result.ok flag is set to False when the decryption process is completed

HOWEVER if I look to this location where I wanted to have my decrypted file '/Users/test/Desktop/test/test9yetqku/testnp2n7cfq' I can see the actual content decrypted!

I am not really sure what Is happening in the background but I believe that the Crypter instance variable self.ok status is not set yo True for some reason within the python-gnupg library.

I have been testing the same thing using the gpg binary v 2.0.22 ( I am using the same gpg version with the python-gnupg library) and I was correctly able to decrypt the file without no errors.

If you would have any idea would be much appreciated. Currently it looks to me to be a bug in the library but I'd like to hear you guys opinion : )

Thanks!

[Vinay Sajip]

gpg 2.0.22 is pretty old. Do you get the same results with newer versions of gpg? (Currently at 2.3.7 or 2.2.36 for long term support.) It may be that 2.0.22 doesn't correctly output the messages that other versions do. The result.ok is set to True when a message [GNUPG:] DECRYPTION_OKAY (analogous to the PLAINTEXT you mention) is received. Perhaps you can have a look at the log and see if that message is printed by your gpg?

[nello]

Hi Vinay, thanks for taking some time to answer!

I will definitely try with a newer version and report over here the result. 

However I thought there was some discouragement to utilise gpg version greater than 2.1 and the python-gnupg library, hence I sticked this version since I have found some notes on the python-gnupg documentation talking about some race conditions occurred and incompatibilities found during the tests 

[Vinay Sajip]

No discouragement, and for a security-oriented package like GnuPG, one needs to keep reasonably current or risk being exposed to vulnerabilities. However, the 2.1 transition wasn't especially smooth due to some backward compatibility niggles. Can you point me to which part of the documentation was of especial concern?

As far as I know the GitHub action tests for the project run with GnuPG 2.2.x or 2.3.x.

[nello]

The part of the documentation are the following 

"By default, passphrase cannot be passed via streams to gpg unless the line allow-loopback-pinentry is added to gpg-agent.conf in the home directory used by gpg (this is also where the keyring files are kept). If that file does not exist, you will need to create it with that single line. *Note that even with this configuration, some versions of GnuPG 2.1.x won’t work as expected*. In our testing, we found, for example, that the 2.1.11 executable shipped with Ubuntu 16.04 did’t behave helpfully, whereas a GnuPG 2.1.15 executable compiled from source on the same machine worked as expected. Support for GnuPG 2.1 is limited, because that version of GnuPG does not provide the ability to prevent pinentry popups in all cases. *This package sends passphrases to the gpgexecutable via pipes, which is only possible under GnuPG 2.1 under limited conditions and requiring end-users to edit GnuPG configuration files*"

I thought that this would be referred to as everything greater than version 2.1.

Does this mean that version 2.2 is fully supported by python-gnupg? This question is currently going out from the thread I opened, but will help me to understand if I can can test further by using gpg binary 2.2 and hopefully solve the issue I reported before.

[Vinay Sajip]

Yes, 2.2 and 2.3 are supported, and as I mentioned, the GitHub Actions tests run on a combination of 2.2 and 2.3. In addition, I test against 1.4.x locally. The documentation refers to 2.1 because it introduced some changes that users of the library needed to be aware of. Anyway, 2.0/2.1 are not recommended by the GnuPG project as too old (the long term support is for 2.2). The documentation also referred to some problems with 2.1, because 2.1 users needed to be aware of them, and which were I suppose superseded with the newer versions of gpg that are now in wide use.

[nello]

So I setup my test env using gpg 2.2 configured with my application. The result using the newer version is the same than the older one, was good to see anyway that I can work with the newer version.

However I figured out what is the problem. The file that I am actually trying to decrypt is not really encrypted but just compressed. From the gpg --list-packets and pgpdump output I showed before it is possible to notice this particular. Eventually the python-gnupg library does its job correctly since there is no real decryption process happening in the behind scene. Would be nice to have some better logging to understand that the files were not correctly encrypted. Not sure if this is possible on the python-gnupg library layer or not. 

[Vinay Sajip]

Logging will show all the communication between the process using python-gnupg and the gpg subprocess it spawns, but it's not really clear if the information provided by gpg is enough to describe what's really going on in the scenario you mention, or in other less common scenarios.

[nello]

Sounds good thanks !