Please briefly try to reproduce on Windows with Gpg4win 5.0.2. At lot has changed since this ticket was created so that it might be fixed already.

I cannot reproduce the empty dialog on Linux with the current build. I always see a correct result dialog for the readable file.

We use individual texts now that all follow the pattern "Detailed results of import from ..." for import from file (file name is displayed), clipboard, notepad, smart card, WKD (URL is displayed), server ("keyserver" or "LDAP server").

Note: This isn't included in Gpg4win 5.0(.2).

Note: This isn't included in Gpg4win 5.0(.2).

Note: This isn't included in Gpg4win 5.0(.2).

Note: This isn't included in Gpg4win 5.0(.2).

I stand partially corrected. Apparently, pinentry-efl also sets close_button. For Gpg4win that's irrelevant because we ship pinentry-qt which doesn't have this IMHO contra-intuitive behavior (and pinentry-w32 where I don't know how it behaves).

Upstream MR for reading system config files before user config files: https://invent.kde.org/frameworks/kconfig/-/merge_requests/436

pinentry-tty and pinentry-curses support GPG_ERR_FULLY_CANCELED by Ctrl-C. But other pinentry implementations have no support (only GPG_ERR_CANCELED).

I'd also like to point out that changing the error code from GPG_ERR_CANCELED to GPG_ERR_FULLY_CANCELED could cause regressions in applications.

Merge request for KMessageBox: https://invent.kde.org/frameworks/kwidgetsaddons/-/merge_requests/339

How do you want to decide whether to show two "Cancel" buttons? How would you call those two "Cancel" buttons? For decryption I can imagine that for example "Try Next Key" and "Cancel Decryption" (or even just "Cancel") would make clear what happens.

Any further improvements will have to go in a new ticket when we have a plan. I'll close this one.

ok, lets go with the message box.

Relevant part from T6793: Cleanup temporary files / dirs with decrypted content:

If this definition is OK

@bernhard Thank you for the link.

In T8076#215372, @werner wrote:

If you specify a primary key the primary key shall be deleted. If there is only an offline or token based primary it can't be deleted. This is what the user requested. We can't change this because otherwise subkeys might be unintentionally deleted.

What is an "incomplete team key" - a standard offline secret key (i.e. one with only secret subkeys)?

It would be used for key creation just like the legacy options PGPKeyType and RSAKeySizes were used (and still can be used but only for RSA with different key sizes).

If you specify a primary key the primary key shall be deleted. If there is only an offline or token based primary it can't be deleted. This is what the user requested. We can't change this because otherwise subkeys might be unintentionally deleted.

I guess the behavior changed with gpg 2.4, i.e. "With gpg 2.4 (or later), ..."

Shall that be used for key creation or shall a warning be displayed when a non-allowed key is used (receive or send)?

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

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.

@ebo, I try to answer your question. As I wrote, the behavior of gpg implementations are different (for a reason). I'm not sure if you suggest the change of behavior of gpg 2.4.

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?

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.

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.

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 letting us 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 be changed to ignore CANCEL status and to handle complex cases; I think that it's not easy change.

We should also change the "donate" button to Gpg4win then and the text to "voluntary payment".

as T8022 was backported, this one should be backported, too, if possible. I'll add the tag

I guess those things need to be changed in Kleopatra after @gniibe made the changes in scd. I'll add a Kleo tag for discussion, as we should probably make several tickets from this.

Gpg4win-5.0.1 still shows case 1. (just reproduced.)

Should be tested (but unclear, how): ability to read / send (with both organization/personal accounts)

Ok, thanks. Closing the mail in Mailviewer will remove all temporary opened attachment files, so I'll set this to resolved.

Current state: T6793: Cleanup temporary files / dirs with decrypted content

Looks good to me on gpg4win-5.0.2-beta2 @ win11.

• local conf after 2 saves (additional entry in local conf):
  
• local conf after 2 saves (additional entry in global conf):
  

Looks almost good to me on gpg4win-5.0.2-beta2 @ win11.

It doesn't look like much was improved on Kleopatra side in gpg4win-5.0.2-beta-2 @ win11.

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

gpg4win-5.0.2-beta-2 @ win11:

Looks good to me on gpg4win-5.0.2-beta2 @ win11.

Additionally, the action is no longer offered for keys with an encryption-capable secret primary key without secret encryption subkey.
And sharing the secret signing subkey isn't offered anymore if this is a card key.

Is this still a requirement?