A quick check with passing ASSUAN_PIPE_CONNECT_DETACHED does not changed anything.

I wonder whether rA3bccb33ccd9028ff505d9979fd6c8a37393b892d which changes Assuan's waitpid function for Windows is well aligned with the my_waitpid in gpgme's assuan-support.c (which does nothing). gpgme creates a detached process in most cases but for gpgsm assuan_pipe_connect is used without the ASSUAN_PIPE_CONNECT_DETACHED flag.

Another data point is that the faulty versions use libassuan 3 with a slightly changed API. May one of the follwing chnages cause the problem?

Although in VSD 3.2.2 we get no warning when configuring S/MIME debugging wrong we then get a nice message "Configuration error" when trying to encrypt with S/MIME, instead of gpgsm hanging without any message at all:

Logging all

The issue also occurs in VSD-3.3.2 and 4win-4.4.1 but not in VSD 3.1.26

OK on Linux now with new enough versions (Fedora 42).

Tested with Fedora 42 (which includes gpgme 1.24.3): this works now, you can drag a public or secret key from Kleopatra to a file manager to export the public key.

Fixed and backported for VSD 3.4

Solved by focusing the result message after the notepad operation is complete. I think that's an acceptable compromise for ensuring that users of assistive tools are informed about the result even if the focus is moved to a different UI element (which, in general, should be avoided because users can get lost).

Finally came around to check this.
On Fedora with Kleopatra 25.04.03, gpg 2.4.5 and pinentry 1.3.1 the pinentry window ist above the Kleoaptra windows.

That look s like a problems with logging to stderr in --server mode. On Windows fds 0,1,2 are special.

Looks good to me on gpg4win-5.0.0-beta357 @ win10 for the following migrations (as stated in the description):

• gpg4win 4.3.1 -> gpg4win 5.0
• gpg4win 4.4.1 -> gpg4win 5.0

Looks good to me on gpg4win-5.0.0-beta357 @ win10.

Do you have a gpgme log?

I created a new issue for the "Keine Daten" error: T7768

closing, rest in follow up ticket.

Turns out the cause is a wrong entry in the gpgsm.conf. Setting "dbug-level basic" without specifying an output file.
And encrypting a file is likewise affected.

Test on Windows by overwriting gpgtar from gpg4win-5.0.0-beta357 and also tested on Linux. Debian packages with patches are already available.

Kleopatra from VSD installations should now use gpgv from the GnuPG installed by VSD when verifying the signature of the VERSION file. GPD and Gpg4win installations both use gpgv from the GnuPG installed at the value of the registry key "Software\\GnuPG:Install Directory".

Closing this ticket, the task is done. Further improvements should go into a new tickets after we decided what we want.

Ok, setting this to done, but not resolved so that timegrid will notice it and make a new ticket with more information for the "no data" message.

If an error occurs then we emit a failure. But if gpg crashes then gpgme just sees a broken pipe.

But we emit a failure at the end of the gpg process; aren't we?

This might be related to the recent changes in now we spawn processes. Using gpgtar [...] --status-fd=3 3>a.log shows something different than directly using --status-fd=2. Do we handle the process termination correctly; i.e. wait for all status-fd output?

well the messages are improved, if we want to improve them further, this should go into a new ticket.

I assume you only forgot to move this to testing, as this is solved.
We now have separate windows for the notepad, several ones can be opened now.
Checked with Gpg4win-5.0.0-beta357

Some lines from the log:

2025-07-30 12:35:29 gpgme[716.23bc]   _gpgme_io_read: check: [GNUPG:] DECRYPTION_KEY 46ED5D7758C1BD71C27AF928
2025-07-30 12:35:29 gpgme[716.23bc]   _gpgme_io_read: check: FFA2FCCB2EC589F8 98111E67AE06F2BEFD2BDE10C5D6C91
2025-07-30 12:35:29 gpgme[716.23bc]   _gpgme_io_read: check: 9005F36A4 u<LF>
2025-07-30 12:35:29 gpgme[716.23bc]   _gpgme_io_read: check: [GNUPG:] BEGIN_DECRYPTION<LF>
2025-07-30 12:35:29 gpgme[716.23bc]   _gpgme_io_read: check: [GNUPG:] DECRYPTION_INFO 2 9 0 0<LF>
2025-07-30 12:35:29 gpgme[716.23bc]   _gpgme_io_read: check: [GNUPG:] PLAINTEXT 62 1753871344 <LF>
[...]
2025-07-30 12:35:29 gpgme[716.23bc]   _gpgme_io_read: check: [GNUPG:] NEWSIG<LF>
[...]
2025-07-30 12:35:29 gpgme[716.23bc]   _gpgme_io_read: check: [GNUPG:] KEY_CONSIDERED F8D51DE0EE16E9B57009B8DE
2025-07-30 12:35:29 gpgme[716.23bc]   _gpgme_io_read: check: 458612006D8E6F0D 0<LF>
[...]
2025-07-30 12:35:29 gpgme[716.23bc]   _gpgme_io_read: check: [GNUPG:] GPGTAR_EXTRACT 2 0 0 0 0 0 0<LF>
[...]
2025-07-30 12:35:29 gpgme[716.23bc]   _gpgme_io_read: check: [GNUPG:] SUCCESS<LF>
[...]
2025-07-30 12:35:29 gpgme[716.808] gpgme:reader: check: ctx->hdd=0x000001b90c8a6a60 got EOF (broken pipe)
[...]
2025-07-30 12:35:29 gpgme[716.23bc]   _gpgme_cancel_with_err: enter: ctx=0x000001b90c854430 ctx_err=117440570, op_err=0
[...]
2025-07-30 12:35:29 gpgme[716.1e08] gpgme:reader: check: ctx->hdd=0x000001b90c8a68c0 got EOF (closed by us)
[...]
2025-07-30 12:35:29 gpgme[716.23bc] gpgme_op_decrypt_ext:186: error: No data <GPGME>\n
2025-07-30 12:35:29 gpgme[716.23bc] gpgme_op_verify_result: enter: ctx=0x000001b90c854430 
2025-07-30 12:35:29 gpgme[716.23bc] gpgme_op_verify_result: leave: result=0x000001b90c7d1150
2025-07-30 12:35:29 gpgme[716.23bc] gpgme_get_protocol: call: ctx=0x000001b90c854430 ctx->protocol=0 (OpenPGP)
2025-07-30 12:35:29 gpgme[716.23bc] gpgme_op_decrypt_result: enter: ctx=0x000001b90c854430 
2025-07-30 12:35:29 gpgme[716.23bc] gpgme_op_decrypt_result: check: ctx=0x000001b90c854430 result: recipient: keyid=FFA2FCCB2EC589F8, pubkey_algo=302, status=Success
2025-07-30 12:35:29 gpgme[716.23bc] gpgme_op_decrypt_result: leave: result=0x000001b90c5e3290

-> there's a broken pipe; _gpgme_cancel_with_err has ctx_err 117440570 = (GPGME, No data)
-> gpgme_op_decrypt_ext reports an error: No data <GPGME>\n
-> There doesn't seem to be a verify result (although the archive is signed and encrypted)
-> There is a decrypt result with status Success

I had a quick look at the status messages that gpg emits. Unfortunately, gpg doesn't emit a status message after successfully signing a key. So, we may have to check whether the signed key really has a new certification to ensure that the operation succeeded. And we should make future version of gpg emit a success status.