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.

tested with Gpg4win-5.0.0-beta357 (GnuPG 2.5.11):

The card returned these 32 bytes:

1883ba0d1cacda6f357ad9caa062ebd7b3a07291a7788565caf38973bf414286

agent_card_pkdecrypt however returned 33 bytes:

411883ba0d1cacda6f357ad9caa062ebd7b3a07291a7788565caf38973bf414286

Thus the indicator byte is 0x41. The specs (librepgp, rfc4880bis) say:

The fix should be available in gpg4win-5.0.0-beta350.

next version:

Besser: The signing certificate is not certified by you or a trusted person.

not sure if this really is an issue, maybe for a person proficient with a a screenreader the behavior ist ok, after the fix of the show/hide button is done?

Regarding the "Keine Daten" on corrupted message: the diagnistics says e.g.: "gpg: Prüfsummenfehler; c83745 - f75c60"

Looks good to me on gpg4win-5.0.0-beta345 @ win10

Looks good to me on gpg4win-5.0.0-beta345 @ win10

Looks good to me on gpg4win-5.0.0-beta345 @ win10

Looks good to me on gpg4win-5.0.0-beta345 @ win10

Looks good to me on gpg4win-5.0.0-beta345 @ win10

Looks good to me on gpg4win-5.0.0-beta345 @ win10

On gpg4win-5.0.0-beta345 @ win10 the progress bar is shown:

Ah, i missed the description edit. Then it looks good to me.

Looks good to me on gpg4win-5.0.0-beta345 @ win10

seems not to be included in gpg4win-5.0.0-beta345 yet

Another suggestion for the changed button text was simply "List Certificates" as the context implies which those will be. I like it.

tested with Gpg4win-5.0.0-beta345

Backported for VSD 3.4

not mentioned in the test for v3.1.26, and checksums are no important part of the software

Done for gpg4win 5 and backported for VSD 3.4 (provided that the gpg4win-4-branch will be used for VSD 3.4).