After choosing "Save" in the first "Secret key backup" window, the pinentry comes up.
If I hit "Cancel" the behavior is the same as hitting "OK", the second pinentry window comes up.
Regardless of which button I choose next the error window "Secret key backup error" pops up.
On "Cancel" I would expect either silent abandonment of the backup or a message like "operation cancelled".
| rKLEOPATRA Kleopatra | |||
| rKLEOPATRA4a3dcec0428a Do not export anything if the user canceled the operation | |||
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | • ebo | T6090 Kleopatra: "Cancel" in the password dialog of "backup secret keys" has no effect | ||
| Resolved | • ebo | T6093 gpg: Continues export of secret key if first passphrase dialog was canceled |
The second pinentry window comes up to ask for the passphrase that protects your subkey. Usually, gpg will try to use the passphrase entered for the primary key also for the subkey, but since you canceled the first pinentry there's no passphrase to re-use.
If I cancel the first pinentry and enter the correct passphrase in the second pinentry, then the secret subkey (secret sub key packet + signature packet) is exported. Kleopatra reports success which is only half correct since the backup of the primary key was canceled. And it's unclear whether the result of the export is actually usable by gpg, i.e. whether it can be reimported. (Update: A quick check seems to indicate that gpg cannot import a secret sub key packet without a secret key packet. This is supported by the way the export of secret sub keys works.)
Kleopatra (and probably also gpgme) currently has no way to know whether the user entered no passphrase or a wrong passphrase, or whether the user canceled the pinentry. That's why we show an error message telling the user that they might have entered no or a wrong passphrase.
Conclusion:
It turns out that gpg does report an error via status-fd, but it doesn't report via status-fd that the operation was canceled (Update: The error code 83886179 in the status message corresponds to GPG_ERR_CANCELED, i.e. gpg reports that the user canceled the operation.)
$ gpg --status-fd 1 --export-secret-keys --armor -- 3A8536D46F57779C49F0CF542C0444CB59852D29 [GNUPG:] KEY_CONSIDERED 3A8536D46F57779C49F0CF542C0444CB59852D29 0 [GNUPG:] PINENTRY_LAUNCHED 6899 qt 1.2.1-beta1 /dev/pts/47 xterm-256color :0 20600/1000/5 1000/100 0 gpg: key 79BF2044FA53B3A492B361882353B5828F9B391C: error receiving key from agent: Operation cancelled - skipped [GNUPG:] ERROR export_keys.secret 83886179 [GNUPG:] PINENTRY_LAUNCHED 6907 qt 1.2.1-beta1 /dev/pts/47 xterm-256color :0 20600/1000/5 1000/100 0 -----BEGIN PGP PRIVATE KEY BLOCK----- nIsEX+Bq3xIKKwYBBAGXVQEFAQEHQDSKsmsDttOBBZ8Yk95cpMF3QNK9NpbCK2Mk [...] =6e8K -----END PGP PRIVATE KEY BLOCK----- [GNUPG:] EXPORT_RES 1 1 0
Kleopatra now silently ends the "backup secret key" operation if the password dialog was canceled.
The issue that gpg shows a second password dialog if the first one was canceled is handled by T6093: gpg: Continues export of secret key if first passphrase dialog was canceled.
Works here with gpg 2.3.8-beta58 on Linux. Maybe gpg 2.2 does not properly report the cancelled pinentry.
Please re-test with GPGME_DEBUG=8 and paste the output.
Thanks. It seems gnupg 2.2 is missing rG605ab99912ac: gpg: Report an error for receiving key from agent.. I'll backport this commit.
I have now backported the missing error reporting to gnupg 2.2 (rG6f0066db2c87: gpg: Report an error for receiving key from agent.). Please retest once gpg 2.2.41 is included in GnuPG (VS-) Desktop 3.x.
The "Secret key backup error" does not appear any more.
But if I hit "cancel" on the pinentry window, still a second pinentry window for the subkey pops up. No matter if I give the correct password in the second pinentry window or not, the backup is silently abandoned.
The backup should be abandoned directly after the first "cancel".
In contrast, if I go through with the backup, no pinentry for the subkey appears (as we assume that the user always wants to export with all subkeys).
