Noticed that one subcase of T2069 was not fixed:
If you cancel a password change for a key in the first Pinentry window, a second Pinentry opens for the first subkey. And so on for potential further subkeys.
This happens regardless of how you abort (either cancel or close the window).
And regardless of if you abort in the Pinentry window for the old password or the new one.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T6491 Pinentry-Qt: Password prompt for each subkey if password change is cancelled | ||
| Resolved | • ikloecker | T6510 GpgME++: Treat GPG_ERR_FULLY_CANCELED as GPG_ERR_CANCELED in GpgME::Error | ||
| Resolved | • ikloecker | T6513 Kleopatra: Require GpgME 1.21 |
For me it works if I fully cancel (i.e. close the Window at the first prompt):
$ gpg --passwd -v --debug ipc FE894309B6844A3004FE8BF9476CAB1C3623CAA6 [...] gpg: DBG: chan_4 -> PASSWD 9111ED65FE0801A9C0E7FAF09EEFF53677BB9219 gpg: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 7481 gtk2 1.2.0-beta45 /dev/pts/9 xterm localhost:11.0 20620/1000/5 1000/1000 0 gpg: pinentry launched (7481 gtk2 1.2.0-beta45 /dev/pts/9 xterm localhost:11.0 20620/1000/5 1000/1000 0) gpg: DBG: chan_4 -> END gpg: DBG: chan_4 <- ERR 83886278 Operation fully cancelled <Pinentry> gpg: key 476CAB1C3623CAA6/476CAB1C3623CAA6: error changing passphrase: Operation fully cancelled
I see the problem: The Qt Pinentry does not implement the BUTTON_INFO status and thus we don't get a fully canceled error back (gpg-agent maps the cancel error to fully-cancel if the close button was used). Should be easy to fix in pinentry (set pinentry->close_button in the close eventhandler).
As a high level interface, kleopatra should always cancel the entire process. I am right now not sure how it is implemented in Kleo, though.
Setting close_button when the user rejected the pin entry (by pressing the close button, the Cancel button or Esc) causes fully canceled. Unfortunately, Kleopatra (and in fact GpgME::Error) has no idea that fully canceled should be treated as canceled and not as error. Therefore, Kleopatra shows an ugly error message:
An error occurred while trying to change the passphrase for [...]:
Operation fully cancelled
To avoid this ugly and confusing error message, we need to add support for "fully canceled" to GpgME::Error and wait until Kleopatra requires the next version of GpgME. Then we can revisit the "multiple prompts" issue. Otherwise, we'd have to change a bazillion checks of the results of GpgME operations in Kleopatra.
I think GPG_ERR_FULLY_CANCELED (which was introduced with the commit log "Fix for W32CE" :/ ) should never have been communicated to users of gpg, but should have been treated only as internal error code and should have been converted to GPG_ERR_CANCELED in status lines.
I have set T6513: Kleopatra: Require GpgME 1.21 as blocker for this issue because, in my opinion, showing the above mentioned "Operation fully cancelled" error message is from a user perspective worse than showing multiple password prompts.
I'm also lowering the priority to Normal.
Making pinentry issue "fully canceled" if the user clicks Cancel breaks decryption of data that is encrypted with multiple keys of the owner. The user woudn't be asked for the password of their second key if they canceled the pinentry for the password of the first key.
I don't think this can be fixed in pinentry because pinentry lacks the context of the questions and thus doesn't know when a hard cancel ("fully canceled") is desired and when a soft "cancel" is desired. I think that needs to be handled/decided by the caller of pinentry.
This issue looks still the same from the user perspective as in the task description with Gpg4win 4.4. Therefore tagging it for gpd5x