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.
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.