gpg-agent.log starts with

2024-12-03 10:11:12 gpg-agent[2816] Der Socket kann nicht an `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent' gebunden werden: Unknown error
2024-12-03 10:11:12 gpg-agent[2816] secmem usage: 0/32768 bytes in 0 blocks

Looks like gpg-agent tried to bind the socket and immediately exited when this failed. The logs of gpg-agent continue 48 seconds later with

2024-12-03 10:12:00 gpg-agent[6492] Es wird auf Socket `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent' gehört
2024-12-03 10:12:00 gpg-agent[6492] Es wird auf Socket `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent.extra' gehört
2024-12-03 10:12:00 gpg-agent[6492] Es wird auf Socket `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent.browser' gehört
2024-12-03 10:12:00 gpg-agent[6492] Es wird auf Socket `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent.ssh' gehört
2024-12-03 10:12:00 gpg-agent[6492] gpg-agent (GnuPG) 2.4.7 started
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x00000084 <- RESET
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x00000084 -> OK
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x00000084 <- OPTION ttyname=/dev/tty
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x00000084 -> OK
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x00000084 <- OPTION putenv=QT_QPA_PLATFORM=windows:darkmode=2
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x00000084 -> OK
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x00000084 <- GETINFO version
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x00000084 -> D 2.4.7
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x00000084 -> OK
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x00000084 <- OPTION allow-pinentry-notify
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x00000084 -> OK
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x00000084 <- OPTION agent-awareness=2.1.0
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x00000084 -> OK
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x00000084 <- HAVEKEY --list=1000
2024-12-03 10:12:02 gpg-agent[6492] no running C:\\Program Files (x86)\\GnuPG\\bin\\scdaemon.exe daemon - starting it
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x000002a4 <- OK GNU Privacy Guard's Smartcard server ready, process 6272
2024-12-03 10:12:02 gpg-agent[6492] first connection to daemon C:\\Program Files (x86)\\GnuPG\\bin\\scdaemon.exe established
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x000002a4 -> GETINFO socket_name
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x000002a4 <- D C:\Users\g10code\AppData\Local\gnupg\S.scdaemon
2024-12-03 10:12:02 gpg-agent[6492] DBG: chan_0x000002a4 <- OK
2024-12-03 10:12:02 gpg-agent[6492] DBG: additional connections at 'C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.scdaemon'

Closing this as duplicate of T7405. That ticket has the better task description as it was made after discussing offline how it could best be done.

closing this as duplicate for the improvement part, the support part is solved, anyway.

T6109 is also closely related and I think it would be addressed by this ticket.

This addresses the same problem as T5950. We should either merge the tickets or just close T5950 (which was more of a support ticket and the reporter has fixed their problem) with reference to this ticket.

Backported for VSD 3.3.x / Gpg4win 4.4.1

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: