Pushed the change: rE1860f6407f83: spawn: Add new function to modify environment.

I have reproduced this with libkleo from our gpg4win/24.05 branch and with gpg (GnuPG) 2.4.6-beta102 (HEAD of STABLE-BRANCH-2-4) and current master of gpgme and all GnuPG libraries. It took just 8 runs until a unittest failed.

gpgme logs for a failed test where the keylisting with gpgsm failed

Thanks for opening a bug report. This is better for our workflow.

But the DEVINFO --watch is required to trigger this hang? Kleopatra does not use this but we see simlar hangs from time to time in the current version.

This is also relevant for VSD 3.3. Backport is not needed, but gpg4win/VSD needs to include current gpgme.

Replacing gpgrt_spawn_actions_set_environ by gpgrt_spawn_actions_set_envchange is not good, as it's exported and already used.

This is a super old bug report, this is likely fixed with a new version of Kleopatra, so I am closing this. If this happen again in the future, feel free to reopen this bug report.

This is no longer possible. The sign/encrypt button is disabled and an info box is displayed.

No reply for a very long time, so I am closing this ticket. This is likely fixed now. Feel free to reopen if this happen again.

No reply for a very long time, let's close this.

gpg4win 4 has been released with unicode support. Closing.

works for VS-Desktop-3.2.94.2-Beta (Beta for VSD 3.2.4)

I knew that we'd need something like D604 when I saw rM409e31458227, but then I forgot about it. :/

should be fixed with D604

We won't fix that for 2.2.

works, the Root-CA of the above example is only shown once any more. Gpg4win-Beta-50

Fixed in master: rGe7891225788a: gpg: Robust error handling for SCD READKEY.

Some would say it is a bug if keys are not shown - even if the algo is not known ;-)

Closing this ticket, as the test version is now obsolete and the new one much improved. I'll open a new one for the remaining issue with scdaemon when I have more information

scdaemon in this case was a broken experiment of mine (trying to see if I can get SoftHSM to work as the OpenPGP card). So this was not a normal, released scdaemon code.

Please send an excerpt from the scdaemon debug output to evaluate why you get somewhat strange looking data. Is this an experimental card? 0xa5 is a common test pattern.

Here is my attempt:

Please write at least a short description and give it a priority

Pretty brief description :-(

It is reproducible bug even with master branch.

on gpg4win-Beta-50 things look much, much better.

I have a look at the log file of gpg-agent.log. I can see that six PKDECRYPT requests are handled simultaneously. I think that it's out of secure memory to decrypt the private key which results pinentry request.

We won't do that for Windows.

Fixed in 2.2 with: rGc33523a0132e047032c4d65f9dedec0297bfbef3

I guess this is now fixed for all branches.

Please go ahead and apply to master. I'll take then care of backporting.

search for "example" works now, Gpg4win-Beta-50

Possible fix:

From 24e8191ab5de7245cf6063be778b6d3ceec4414b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ingo=20Kl=C3=B6cker?= <dev@ingo-kloecker.de>
Date: Tue, 24 Sep 2024 10:44:31 +0200
Subject: [PATCH] gpg: Fix --quick-set-expire for V5 subkey fingerprints

The test with Gpg4win 4.3.1 (using GnuPG 2.4) seems to indicate that:

1. gpg didn't update the trustdb automatically after importing the extended trusted certificate.
2. gpg updated the trustdb automatically after deleting and re-importing the expired trusted certificate, but Kleopatra still showed the certificates signed by the trusted certificate as "certified". This could be a bug in the trustdb calculation (note the log message "Schlüssel C5D6C919005F36A4 ist als ultimativ vertrauenswürdig gekennzeichnet" which could indicate that gpg treats the key as valid although it's expired). On the other hand, my test with GnuPG 2.4 on Linux doesn't reproduce this problem.

Things look good on Windows. A quick test using gnupg24 with backported patches did not show any hangs. More testing will follow next week.

And I can replicate it with the Appimage for VSD 3.2.2, too.

The issue is the same on import on the command line. So it's a gpg issue.

gpgme now checks for a SUCCESS status emitted by gpgtar when creating a signed and/or encrypted archive. If gpgtar is killed (or exits without emitting SUCCESS for some other reason) then the partially created archive is removed and Kleopatra reports a failure.

ok, the following is with Gpg4win 4.3.1.

@werner: I reproduced this before creating the ticket… With a VSD version and a Gpg4win Testversion. I'll add Audit Logs.

Found another thinko; When there is no clients with DEVINFO --watch, the pipe to be notified is not consumed at all (no read). It eventually results blocked by write(2), when the pipe is filled.