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.

The import code related to the trust management did not change since 2018. Thus I doubt it depends on the version.

I'm unable to reproduce the problem with Kleopatra master (Qt 6) and GnuPG 2.4.

It's possible that the file system watcher does not yet support keyboxd. (Ideally, keyboxd would report changes via assuan to processes listening for changes. The file system watcher is obviously just a workaround.)

This fix has the problem that for a signed message where the signing key is not available gpg emits the decryption_failed status line and prints "WARNING: encrypted message has been manipulated". This is because we use log_error to show that the signature could not be verified due to a missing key. The extra check we introduced with rG50e81ad38d2b lloked at the error counter and thus triggered the decryptio failed.

This still seems to be a problem. I was using Outlook 365 version 2408 and the current GpgOL and moving a signed email didn't work correctly. But there seems to be a difference when I move it by using the context menu or by using drag 'n' drop.

Does the file system watcher catch that keyboxd changes its database file below public-keys.d ?

I see. the systemd race of having two gpg-agent processes. The second gpg-agent should eventually go away but than it is already too late.

Sounds very reasonable. Maybe the initial idea was to open the database directly after keyboxd start and before and connections are accepted. My usual try to optimize a mutex away - I should not do this.

I applied rGb804378f183f: kbx: Fix a race condition on DATABASE_HD. in master. Let us see how behavior changes.

I found one problem. This problem may result lock-up on Windows, I suppose.

I mean: two gpg-agent requests simultaneously running DEVINFO --watch.
Single scdaemon, two threads handling DEVINFO --watch simultaneously, by pselect + read.
Two threads waken up, but it was only one thread which can read(2), another was blocked (before the fix).

Kleopatra does a full key listing after an import (triggered by the file system watcher noticing changes in GNUPGHOME). In general, Kleopatra always does full key listings.

You mean it is possible that the initialization function is called by several threads - or that two scdaemon's are running before they realize that one of them is in the way?

How does Kleo's key listing after an import work? Does it do a full listing or just updates the imported keys? Keep in mind that the import merely sets a flag in the trudtdb to be evaluated by the next key listing.

Status messages on successful creation of signed & encrypted archive

2024-09-18 15:21:33 gpgme[3250.d47]     _gpgme_io_read: check: [GNUPG:] PROGRESS gpgtar c 0 3<LF>
2024-09-18 15:21:33 gpgme[3250.d47]     _gpgme_io_read: check: [GNUPG:] PROGRESS gpgtar s 0 62 B<LF>

I don't see how Kleopatra is responsible for updating the trustdb. As Andre correctly commented, Kleopatra sets "no-auto-check-trustdb" only for the initial key listing.

Fixed in rGfc30f7059650: scd: Fix DEVINFO to allow multiple clients.

I realized that I put a bug on POSIX; When multiple clients do DEVINFO --watch, it is possible for scdaemon to hang (waiting pselect and read, read by one, read by another is blocked).

Fixed GnuPG 2.4 in: rG730593affa91: common:w32: Don't expose unused functions.

For now, I'm using this to avoid failure of make check (invoking gpg-agent by gpg-connect-agent).

diff --git a/common/stringhelp.c b/common/stringhelp.c
index 9a2265258..6596c65cd 100644
--- a/common/stringhelp.c
+++ b/common/stringhelp.c
@@ -70,6 +70,22 @@ change_slashes (char *name)
 {
 #ifdef HAVE_DOSISH_SYSTEM
   char *p;
+  /* 0: don't know yet, 1: it's under wine, -1: no */
+  static int semihosted_by_wine;
+
+  /* Under wine, no change.  */
+  if (!semihosted_by_wine)
+    {
+      HMODULE hntdll = GetModuleHandle ("ntdll.dll");
+      if (hntdll
+          && GetProcAddress (hntdll, "wine_get_version"))
+        semihosted_by_wine = 1;
+      else
+        semihosted_by_wine = -1;
+    }
+
+  if (semihosted_by_wine > 0)
+    return name;

libgpg-error fix is done in: rEc2a713fe11e3: w32:spawn: Remove unused function get_max_fds.

I'd vote for the second (utf-8) which is more aligned with our other APIs.

Since CreateProcessW allows two ways for lpEnvironment (one is ANSI environment block, another is Unicode environment block), if we want to support these two ways for users' of gpgrt spawn API, we would offer either:

I'm talking about CreateProcessW and how a user of gpgrt spawn API can specify lpEnvironment (when needed).

Thank you. Applied.

The environment is a property of the C runtime and well defined as a block of concatenated C-strings terminated by a zero length C-string. In case of wmain the C-strings use wchar_t and not char.

Thank you for the bug report and your patch.

Please note that gpgrt_spawn_actions_set_envvars is W32 specific API in libgpg-error. Currently, the behavior with ASCII string is defined.
The patch is an answer in future if we want to extend the semantics supporting UTF-8.

String values are stored as UTF-16, but might not even contain a terminating doublezero since it can be any binary data. Note that on Windows the registry can be used to set environment variables. There "Edit binary data" shows exactly what is in the regkey. So if you use regedit with the String functions you can see that they are converted from latin1 to UTF-16.

The problem might be that we use getenv all over the place and don't specify the content. Frankly, it is not 100% clear to me whether the value of an enbvar need to be a string or can be arbitrary data sans nul? However, I can't remember that I ever wrote any code which did not assume ascii or utf8 for the value.

Here is my attempt:

Use of execve is better (avoiding use of environ).

Fixed in: rA69069bc63e6b: Remove an declaration for an unused function

In T7283#190941, @gniibe wrote:

I can replicate the problem.

The cause of this is that when it's comes with loopback mode, gpg-agent inquires back to the frontend and the buffer overwritten, which results parsing the line wrong.
I'm going to fix.

In T7283#190901, @werner wrote:

y38k problems with some frontends are known for some 32 bit platforms.

Please write a proper bug report and don't expect us to read a reddit thread.

I can replicate the problem.

Fixed.