Backported for VSD 3.4

This task is not really actionable. Moreover, it proposes a technical solution instead of just stating the problem that needs to be solved. There may be better solutions, e.g. in the Notepad I decided to move the focus to the message widget that contains the result to make the screen reader read the result.

I've also fixed the problem that a file named mail.P7M was not treated as encrypted email message. I think this could be tested/verified.

After studying the logs created by NVDA and its source code I strongly suspect that the problem needs to be fixed in NVDA. NVDA tries to avoid repeating the text of common ancestors of the old and the new focus object, but it fails to detect the Create OpenPGP Certificate dialog as common ancestor of the text edit field in this dialog and the Error (child) window.

Fixed by adding a patch for Qt 6 (and a patch for Qt 5 in gpg4win-4-branch for VSD 3.4).

Logging all

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

The gold rule of tab order is that tab order follows the usual reading direction, i.e. line by line from left to right. If you press Enter after entering the password in the first input field then the focus should jump to the second input field.

Do you have a gpgme log?

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

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

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.

I can confirm that the crash is fixed by the change.

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

Ideally, this will be solved for VSD 3.4.