canceling password dialog for decrypting is not recognized correctling.
Closed, DuplicatePublic

Description

If I use DecryptVerifyJob and cancle the password dialog I can't detect this canceling correctly, as it falls back to a general "Decryption Failed" error. So I can't present a user the option to retry another time later. As you will distinguish between errors, that ma be solvable and those that are not.

here the status I see:

GpgME::DecryptionResult(
 error:                GpgME::Error(117440664 (Decryption failed))
 fileName:             <null>
 unsupportedAlgorithm: <null>
 isWrongKeyUsage:      0
 recipients:
GpgME::DecryptionResult::Recipient(
 keyID:              8392A04A0103961A
 shortKeyID:         0103961A
 publicKeyAlgorithm: RSA
 status:             GpgME::Error(0 (Success)))
)
GpgME::VerificationResult(
 error:      GpgME::Error(117440664 (Decryption failed))
 fileName:   
 signatures:
)

decryptResult.error().isCanceled():  false 
decryptResult.error().code():  152

Details

Version
1.8.0
hefee created this task.Apr 22 2018, 10:47 AM
aheinecke triaged this task as Normal priority.Apr 27 2018, 7:24 AM
aheinecke added a subscriber: aheinecke.

I can't reproduce this with GnuPG 2.2.6 or 2.2.7 beta and GPGME 1.11.0 . There I correctly get User Canceled for OpenPGP but "No Secret Key" for S/MIME, also using GpgME++.

But I think this changed over the versions :-/ E.g. I'm sure that for "No Secret Key" I got "Decryption failed" at some point and had to check all the recipients for "No Secret Key" now I get "No Secret Key" directly.

Which GnuPG are you using GPGME with? I could then see If I could reproduce similar behavior with that GnuPG Version to check if it has been fixed in newer GPGME Versions.

hefee added a comment.Apr 27 2018, 8:18 PM

Hey,

I'm using the kdepim-docker for tests, that is based on KDE Neon, that is based on Ubuntu xenial (16.04), so the version for GnuPG2 is 2.1.11-6ubuntu2. Good to know, that the GnuPG version also matters for this stuff.

I closed this as a duplicate of a newer task because I did not find this issue when creating T4561 and there was already work done for T4561.