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".
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 1 2025
Jul 31 2025
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.
Jul 30 2025
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):
Jul 29 2025
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.
Jul 28 2025
Jul 25 2025
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
Jul 24 2025
Another suggestion for the changed button text was simply "List Certificates" as the context implies which those will be. I like it.
Jul 23 2025
tested with Gpg4win-5.0.0-beta345