Kleopatra: Error "no data" on decryption of tar.gpg archive
Testing, NormalPublic
Actions

Assigned To

Authored By

	• ebo
	Jul 30 2025, 12:48 PM

Description

I have reproduced the issue reported via the forum with the newest beta and an archive with two simple text files. The kind of key used seems not to be relevant.

Decryption of the signed+encrypted test archive fails in Kleopatra with "No data". There is no audit log link in the Kleopatra error window.

gpgme_log.txt1 MBDownload

Edit: It seemed to work on the command line but on closer inspection it does not verify the signature but only decrypts the signed and encrypted archive and returns no error:

C:\Users\g10code.WIN-TEST3\Documents>gpgtar --decrypt --verbose --status-fd 2 --batch --yes "Archiv.tar.gpg"
gpgtar: extracting to 'Archiv.tar_1_/'
gpgtar: extracted 'Archiv.tar_1_/test2.txt'
gpgtar: extracted 'Archiv.tar_1_/test.txt'
[GNUPG:] GPGTAR_EXTRACT 2 0 0 0 0 0 0
[GNUPG:] SUCCESS

Details

External Link: https://forum.gnupg.org/t/failed-to-decrypt-archive-tar-pgp-no-data/6699
Version: Gpg4win-5.0.0-beta357

Revisions and Commits

rG GnuPG
	rG5dadef08f050 gpgtar: Do not close stderr when calling gpg.
	rG037e47981374 gpgtar: Fix regression in end-of-archive detection.

Related Objects

Mentioned In: T7756: Release GnuPG 2.5.12

Event Timeline

• ebo created this task.Jul 30 2025, 12:48 PM

• ebo triaged this task as High priority.Jul 30 2025, 1:49 PM

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

• ebo updated the task description. (Show Details)Jul 30 2025, 2:35 PM

• ebo updated the task description. (Show Details)Jul 30 2025, 3:29 PM

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?

• werner raised the priority of this task from High to Unbreak Now!.Jul 30 2025, 4:14 PM

• werner added a project: gnupg26.Jul 30 2025, 7:49 PM

• werner claimed this task.Jul 31 2025, 10:51 AM

• werner added a commit: rG037e47981374: gpgtar: Fix regression in end-of-archive detection..Jul 31 2025, 10:57 AM

• werner added a commit: rG5dadef08f050: gpgtar: Do not close stderr when calling gpg..Jul 31 2025, 11:34 AM

• werner changed the task status from Open to Testing.Jul 31 2025, 11:35 AM

• werner moved this task from Backlog to WIP on the gnupg26 board.

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

• werner lowered the priority of this task from Unbreak Now! to Normal.Aug 4 2025, 8:09 PM

• ebo moved this task from Backlog to WIP on the gpd5x board.Fri, Aug 15, 12:07 PM

• werner mentioned this in T7756: Release GnuPG 2.5.12.Tue, Sep 2, 2:55 PM

• werner moved this task from Done to QA on the gnupg26 board.

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