Solved for gnupg 2.2, 2.4 and 2.6. GPGME support still missing.

Also done for gpgsm in gnupg26 (master)

The fix should probably be backported to gnupg 2.2 and 2.4.

I'm still seeing the same problems both with current master and 2.2

FWIW, the cache has not been implemented in 2.4 (which will be used for the next gpg4win) and thus there is no need for a fix there.

Was fixed last Thursday with commit rG69a8aefa5bf77136b77383b94e34ba784c1cce89 for 2.2 and will soon make it to master.

gpg4win 4 has been released with unicode support. Closing.

Pushed the fix for exporting OpenPGP v5 key: rG57dce1ee62c2: common,gpg,scd,sm: Fix for Curve25519 OID supporting new and old.

With the new patch you get this now:

[GNUPG:] KEY_CONSIDERED F40ADB902B24264AA42E50BF92EDB04BFF325CF3 1
[GNUPG:] ERROR add_adsk 53
gpg: key "F40ADB902B24264AA42E50BF92EDB04BFF325CF3!" not found: Unusable public key
gpg: Did you specify the fingerprint of a subkey?
[GNUPG:] FAILURE gpg-exit 33554433

Yes, gpg logs "invalid ADSK ... specified", but it doesn't emit a status error. This needs to be changed in gpg.

Test on a dedicated Windows box (T 460, i5-6300U@2.40GHz, harddisk):

Overall effect of these changes tested on a small Windows VM is only 47 -> 26 seconds. Did also tests with --kbx-buffer-size but that does not make it better than the default, either.

The OID is used for fingerprint computation, which complicates things.

Using the shorter OID for v5 is on purpose; thus we need to fix the export.

Will be available in 2.2.45 and 2.5.2

Now we are at 4 seconds. Available in master and 2.2.

With that patch we are down to about 6 seconds.

Fixed in pinentry 1.3, when using GnuPG 2.4 or later.

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

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;

See new subtask T7290 for smartcards and the link entries mentioned above.

Thank you for the bug report and your patch.

Good idea. Done for master and gnupg24

Right, thanks for the information. Might I suggest printing a warning when --keyring is given?

The --keyring option is deprecated and does not work at all if the keyboxd is used. This is the default for a new GnuPG 2.4 installation.

Followup: Using edge and a restart did not trigger the installation of of CN=ISRG Root X1,O=Internet Security Research Group,C=US.

I've checked the windows configuration and the automatic update of root certificates is not switched off.
Looking into the windows events view I did not see the certificate update, but after a while I did (restarts, edge attempts installation of firefox). So probably the edge view may have triggered this update, but it did not show directly in the cert store and thus not for Gnupg.

next I'll turn up dirmngr's logging

Since only https fails for you.

Hi Bernhard,

I think we can close this as Wontfix since it is our opinion to wont fix this issue. If there should be more prevetion of accidents it would probably be better to have the user type in "DELETE" or "YES". Anything else then another click confirming a popup. Since this will just be clicked away through muscle memory. This came up again in T7211: Kleopatra: configuration option to prohibit deletion of certificate with secret key

Fixed in: rG1e6b96577f68: gpg: Fix agent_probe_any_secret_key.

Verified.

Thank you for your report.

Pushed the change: rGaf6c47b2910f: common,kbx,tests: Clean up the PIPE function API.

Push the change: rG953dd67368ce: Use gpgrt_process_spawn API from libgpg-error.
Please test.

Thank you for your report. We are about to migrate to use the gpgrt_spawn_process API.
(In our development history, it was originally implemented and tested as gnupg_spawn_process API and moved to libgpg-error.)

In case you run into problems installing the bzip2 part w/o root rights, you need to apply rGc333e9dad66 to set the PREFIX make variable also for bzip2.

Thank you for the patch.

Reading the original bug report it is clear that this is not a gpg bug but a problem in the Python code. This should only be read as utf-8 if the NOTATION_FLAGS line indicated that this is human readable.

Since it is only me, let us set the "Wishlist" priority on this task.

For my testing environment, I have this patch for now.

All applied and more fun with cherry picking in the future ;-)

Recall that on windows you have a current working directory per drive. Thus only LETTER:\foo is a full patch - or an UNC (\\SERVER\foo).

The executable is on Z: drive (Z:\home\gniibe\build\mingw-i686\gnupg\agent\gpg-agent.exe) in the emulated environment.
Perhaps, when the path is absolute path with /, it is interpreted as on the drive Z:.