gpgme decryptverify indicating wrongly an error.
Open, NormalPublic



if I create a file simply via "gpg -d " and than afterwards parse this via DecryptVerify method I get:

log_gpgme_backend: End no plainText. Error:  true

and the DecryptionResult/Verify Result:

 error:                GpgME::Error(117440570 (No data))
 fileName:             <null>
 unsupportedAlgorithm: <null>
 isWrongKeyUsage:      0
 keyID:              0CCE435AA7CCDA3B
 shortKeyID:         A7CCDA3B
 publicKeyAlgorithm: RSA
 status:             GpgME::Error(0 (Success)))

 error:      GpgME::Error(117440570 (No data))

Ican understand, that the VerificationResult returns with an error, because the data wasn't signed. But why DecryptionResult indication an error? Because the data could be encrypted successfully for 0CCE435AA7CCDA3B. And I get succesfully the decrypted data in the signal.


hefee created this task.Oct 27 2017, 2:16 PM
werner added a subscriber: werner.Oct 27 2017, 11:02 PM

"gpg -d" decrypts data why do you think you can decrypt or verify it again?

hefee added a comment.Oct 29 2017, 3:04 PM

Oh sorry i mixed my explanation. I create a normal encrypted file with gpg --encrypt and this file can be decrypted successfully with "gpg -d".
But if I give that encrypted file to gpgme i get the described error, instead of GpgME::Error(0 (Success))).

These are the testdata, you find in (keep in mind, that the gpgdata is base64 encoded), the keys to decrypt you find under messagecore/autotests/gnupg_home/ in the same repo.

I tried to reproduce this simply by creating an encrypted file with gpgme/test/run-encrypt and then running kleopatra on it "kleopatra /tmp/foo.gpg" kleopatra prints in debug output the decrypt / verify result from GpgMEpp. No error for me.

Also if I take one of the example mails and decrypt the content with Kleopatra it also shows no error and works fine.

Maybe GnuPG 2.1.11 breakage? This was a very broken version.

Can you please post an example msg + key here where you get the error?

hefee added a comment.Nov 17 2017, 6:12 PM

data.gpg is fine and data2.gpg shows this wired behaviour. The difference is at the end of file last two bytes : 0040 vs. 0a40.
Initally i took data.gpg to create the base64 encoded version for the message.

% GNUPGHOME=T3471/gnupg_home  gpg-agent --daemon gpg -d T3471/data.gpg
gpg: WARNING: unsafe permissions on homedir '/T3471/gnupg_home'
gpg: encrypted with 2048-bit RSA key, ID 0CCE435AA7CCDA3B, created 2009-11-13
      "unittest key (no password) <>"

% GNUPGHOME=T3471/gnupg_home  gpg-agent --daemon gpg -d T3471/data2.gpg
gpg: WARNING: unsafe permissions on homedir 'T3471/gnupg_home'
gpg: encrypted with 2048-bit RSA key, ID 0CCE435AA7CCDA3B, created 2009-11-13
      "unittest key (no password) <>"
gpg: [don't know]: invalid packet (ctb=0a)
werner triaged this task as Normal priority.Apr 17 2018, 10:43 AM
hefee added a comment.Apr 27 2018, 8:24 PM

@aheinecke maybe recheck with GNUPG 2.2.6 or 2.2.7.

werner edited projects, added gnupg, Not A Bug; removed gpgme.Jul 16 2020, 3:06 PM

I don't see any error here. There is a trailing LF on the binary data which gpg rightfully complains about.

The question is how you created that data in the first place. Is that the the first octet of the MIME boundary?

I am going to close this bug soon unless you are still interested in this old report.