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.

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?

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

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?

There's something wrong. I suspect that gpgme is too old. Yeah, gpg4win 5 uses gpgme 2.0.1 and gpgmepp/gpgmeqt 2.0.0. The changes to force deletion was added later.

well, you are showing 4 pinentry-qt windows above. The reference to pinentry meant those windows.

In T7502#214891, @ebo wrote:

Q3: Would you make the text in "Certify shared secret key?" wrap?

In T7502#214891, @ebo wrote:

Q2: For 2 and 3 "Certify new certificate? You have imported an new certificate (public key) […]" is not strictly correct, this could be confusing. Maybe we could use the "Certify shared secret key?" instead and change it a bit to make it fit this case too? How about starting with:
"You have imported a shared secret key / a key without primary part." And then leave out the "shared" in the second sentence and in the window title.

In T7502#214891, @ebo wrote:

Q1: Does showing the "Detailed results of importing" make sense for the above cases? One could argue that we could remove it for all single imports where any dialog is shown.

For verification text improvements we have various other tickets, see T8095. I'll add this one as another of those.

@ikloecker said (paraphrased by me):

Curent state in gpg4win-5.0.2-beta-2 @ win11

• it asks for each subkey
• but no pinentry involved

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

Looks good to me on gpg4win-5.0.2-beta2 @ win11 (no de-vs-compliance filter):

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

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