why gpg 2.4? Don't you mean 2.6? I'll add the proper 2.6 tag for avoiding confusion

FYI: We had a VSD support case today where the user complained that they thought the Admin PIN would work because of the tooltip text but it was not accepted. They needed to give the PUK, which is consistent with the state given in this ticket.

Hi @gniibe,
thanks for making progress on the issue.

I was wrong. gpg (scdaemon) needed to be fixed with more changes for the interaction with pinentry.

I pushed my patch for gpg, since it does not break anything, just allow empty passphrase input (to skip).
I also pushed my patch for gpgme. I believe that it's correct.

gpg 2.2 does: when it sees PKT_PUBKEY_ENC it asks a user to try decrypting the session key. when it sees PKT_SYMKEY_ENC it asks a user to try decrypting the encrypted session key by passphrase. When one of tries successes, it use the result (the session key) to decrypt PKT_ENCRYPTED_* packet. When there are multiple PKT_PUBKEY_ENC and PKT_SYMKEY_ENC, gpg 2.2 handles sequentially.

And *.pub is used for Microsoft Publisher documents

From the support angle, the worst of these issues is that the default will not be restored for VS-NfD. But then: nobody has inquired about that yet…

What is fixed, what needs still needs to be done and should go into another ticket?

There is already a hint in the "1st steps" web page and already a ticket to add a hint on incompatible Add-Ons in the documentation.

We need tests to reproduce this.

We need a test $GNUPGHOME with different secret keys to test this scenario:

• expired key
• 2 usable keys (not expired)

I don't understand how to reproduce this. When a key is deleted then nothing referencing this key should remain in the key ring. I don't see why it should matter whether the deleted key was a card key or not.

Marcus suggestion: offer the HTML mail content as attachment.

I've added *.pub and *.sec (since we have test keys with those suffixes even in gpgme).

The proposed changes are a bit in conflict with https://dev.gnupg.org/T8158 because T8158 proposes to show another dialog when clicking "No". I guess "Cancel" would suppress the Certify dialog. "No for all" would have a different meaning. I guess we'd also need a "No for all" button for the following "Certify Shared Team Key?" question so that one can abort being asked for each imported secret key by clicking "No for all" twice.

I have explicitly chosen this tab order so that tabbing through the informational fields on the left isn't interrupted by the "Card Actions" button on the right. The alternative would be to put the "Card Actions" button in the tab order between the last informational field on the left and the table.

I cannot reproduce this problem anymore with Gpg4win 5.0.1. The bug seems to have been fixed in the meantime by changes made upstream.

Done.

A message box would be fine.

I thought Gniibe's comment meant that gpg does report the errors now correctly…
So what is still to be done in gpg?

I don't think that anything of this can be changed in Kleopatra or even gpgme. Kleopatra relies on proper error codes by gpg.

It's impossible to know beforehand (i.e. before the user clicked Save) how the folder is going to be called because it might get a suffix to avoid a collision and this cannot be checked before the user clicks Save. I suggest to remove the useless information where the archive was extracted because it's a temporary location. Instead we could add a message box which tells the user the actual location after the data was moved there.

It is not (easily) possible to check for available keys first, before asking for a passphrase? (Like it is with gpg 2.2.)

I was too optimistic. GPGME is required the following change, too:

diff --git a/src/passphrase.c b/src/passphrase.c
index 140cd03a..d07afa91 100644
--- a/src/passphrase.c
+++ b/src/passphrase.c
@@ -114,6 +114,11 @@ _gpgme_passphrase_status_handler (void *priv, gpgme_status_code_t code,
     case GPGME_STATUS_CANCELED_BY_USER:
       return gpg_error (GPG_ERR_CANCELED);

I'd propose applying the patch of mine above to gpg, and suggest users to input empty pass phrase to skip (instead of cancelling).
This could be a minimum change (only gpg). Or else, gpgme needs to change to ignore CANCEL status; I think that it's not easy change.

Afaict neither QT nor FLTK offer an equivalent to gtk-2's gtk_init_check() so there is no trivial change to get the same functionality.