I'll backport this because this issue is a really bad usability problem for people using the Windows Explorer integration to decrypt files. And the regression risk is minimal.

For me the change fixes the problem on Windows. (I haven't checked if there was a problem on Linux/X11, but I have verified that the change also works on Linux/X11.)

I think you are right, it is fixed. I tried it now again with Gpg4win 4.4 with several cards and it works as you describe.

This also happens if one activates the Kleopatra main window, then activates the Windows Explorer and then starts a decrypt&verify operation.

I have seen this when doing the following:

• Start Kleopatra and minimize its window
• Start decrypt&verify operation for an encrypted archive in Windows Explorer with GpgEX

Gpg4win 4.4.0 has just been released. Creation of encrypted archives has been completely reworked with Gpg4win 4.3.0 already. I could create an encrypted archive containing the two files with GpgEX without problems.

Christoph refers to this post here:
https://forum.gnupg.org/t/readme-4-3-1-en-txt-currently-missing-from-files-gpg4win-org/5845/4

I tried to reproduce this with Gpg4win 4.4.0, but it worked for all PKCS#15 cards I tried (dark blue R&S, Genua, ipt.fraunhofer). As soon as the certificates were imported from the card (and a "Do you trust this root certificate" dialog was canceled) the buttons became enabled.

Gpg4win 4.4.0 has just been released. I cannot reproduce unexpected results when doing a lookup on server. Unfortunately, many keyservers do not publish the user IDs (i.e. name and/or email address) anymore. Kleopatra does not list results without user IDs because GnuPG won't import them anyway.

This has been fixed in the meantime. If you should still experience this problem with Gpg4win 4.4.0 then reopen this ticket.

Gpg4win 4.4.0 has just been released. I assume that this has been fixed in the meantime. In particular, "General error" should happen a lot less. If the problem still occurs with Gpg4win 4.4.0 then reopen the ticket.

This ticket is obsolete

Gpg4win 4.4:
When a keyserver is configured you can now check a box to directly upload the revocation there:

I assume the problem has been resolved because we never got feedback that the problem persists.

Interesting. Just a few days ago I noticed that Kleopatra creates a new tab with the imported certificates except when the import is done via the notepad (or via the clipboard). I guess we could add an option to open a tab with the imported certificates to the import result window.

This problem has been fixed quite some time ago. See https://bugs.kde.org/show_bug.cgi?id=415168.

This doesn't look like a problem in Kleopatra.

We have to take the list of OIDs to ignore into account that can be configured for gpgsm with ignore-cert-with-oid.

We won't revert to the old UI which had its own share of problems. In the meantime Kleopatra supports certificate groups which should help if you often need to encrypt for the same keys.

Closed, since this was documentation for the workaround, four years ago.

Kleopatra now let's gpg deal with I/O directly. This makes decryption with Kleopatra as fast (or slow) as with gpg on the command line. Hence I'll remove the Kleopatra tag.

Just a reminder: with Gnuk 1.2.15 and an ed25519 key PubkeyAuthentication unbound is required for hosts using the new feature.

Then please upload whatever README you want there. My release checklist does not mention any README.

Put it under lower priority, as it's basically programming error.

OK, it's done. closed.

I get this message even with --quiet:

Here is my proposal to avoid unsynched state for data.

diff --git a/src/client.c b/src/client.c
index 410f940..0989984 100644
--- a/src/client.c
+++ b/src/client.c
@@ -250,6 +250,7 @@ assuan_transact (assuan_context_t ctx,
   int off;
   char *line;
   int linelen;
+  gpg_error_t last_err = 0;

Done for 2.5.0.