Today
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.
Yesterday
Ok, thanks. I pushed the powerpc patches to master.
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):
Note that 2.5.11 fixes a regression in 2.5.10 regarding the use of notations for 3rd party signatures. See T7743
I can confirm that the crash is fixed by the change.
Urgs
I pushed the longlong patch: rCb61a7661d017: mpi: Provide the function prototype of __udiv_qrnnd.
Tue, Jul 29
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.
Ideally, this will be solved for VSD 3.4.
Panel Used By
Dashboard | Restricted Dashboard |