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.

I can reproduce this: It works with setuptools 72.1.0 and it fails with setuptools 72.2.0.

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

As far as I know the practice to have separate -dev packages is very common among Linux distributions.

I wonder how common this practice of splitting development material into a separate file might be? It is in place at Alpine, since the file libgpg-error-dev exists. Once the related component is instaled, these messages/strings are printed:; output filtered:

checking for GPG Error - version >= 1.49... expr: warning: '^x-L': using '^' as the first character of a basic regular expression is not portable; it is ignored  yes (1.49)

Does alpine split the development files of libgpg-error into a separate *-devel (or similar) package like most other distros? If yes, then you need to install this development package.

Thanks. Test works in my nightly builds now.

The bug doesn't occur when the normal certification process is used because there we specifically tell gpg which user IDs to sign (excluding the revoked one).

The interactor log shows what's happening:

EditInteractor: 0 -> nextState( GET_LINE, keyedit.prompt ) -> 1
EditInteractor: action result "lsign"
EditInteractor: error now 0 (Erfolg)
EditInteractor: 1 -> nextState( GOT_IT,  ) -> 1
EditInteractor: no action executed
EditInteractor: error now 0 (Erfolg)

gpg asks what to do. Kleopatra answers "lsign".

T6512 is only for gnupg26. In gnupg24 we don't use fd-passing.

That's my badness.
I noticed by the CI at https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror

The changes broke saving of groups after editing. See T7181#190402 and T7181#190448. -> T7268: Kleopatra: Existing groups are not saved after editing them

Please remove the any configuration file changes from kwatchgnupg. That is not a good idea. Launching kwatchgnupg is
a debugging aid and not a regular operation and thus the user can also enable debugging selectively with kleopatra.
kwatchgnupg should listen on the standard socket socket:// - for Windows we don't yet need it because there we don't have sockets anyway. Or well, eventually we will have same but that requires work in watchgnupg and gpgrt for the logging stuff.

works in VS-Desktop-3.2.93.33-Beta

Thanks.