Fixed in 2.4.6.

Fixed in 2.4.6.

I cherry picked your patch for master and 2.4.

For master fixed with rGbb6b38c24010258c7cb2da840d0a088fe43393b3 (Wrong bug id used).
Also fixed for gnupg24.

It works, technically.
But for this to work you have to put the keyword "qual" at the end of the line of the system trustlist.txt file, the user trustlist.txt won't work. Example line:

This looks as if it is resolved. Should I be wrong, you can reopen it.

Werner backported this to GnuPG 2.2.45.

ok, regarding better access to the more detailed error dialog see the above mentioned ticket

Sorry, I've pasted the wrong link, I wanted to paste this one: https://lists.gnupg.org/mailman/listinfo/gnupg-users

Why would I turn to the Windows mailing list when I am a Linux user?

I removed a duplicated comment above.
Please do not duplicate information (no top posting) and keep your descriptions short and to the point.

"BTW, GnuPG 2.3.4 is a very old version."

I've checked and can confirm this is working as intended.

In the story of my life, you are a mythological figure.

Kleopatra just checks if the option "default-new-key-adsk" is set (i.e. it doesn't matter if it's an option with scalar value or list value). The other two options that were changed are not used by Kleopatra.

I reviewed this and there are actually two changes. The first chnage
is a simple string change from

Hello,
I have a hard time to agree that is the right thing for gnupg to throw an error if it successfully imported a revocation certificate for an expired key. This is a meaningful (and not useless) change even if the key is expired.

Tested again on linux with current master (at 18081e2ecf43de2be6ad5a7ca3384e1e2b66914d) and 2.2 (at 5c0383d558cc9112c4c0984a3b2a6c98b29a92ca) - still same behavior.

In T7322#192972, @ebo wrote:

Which is of course technically correct but why can't we have the much more clear "invalid ADSK ... specified"? I think this would help troubleshooting.

Was fixed in master with rG374195e741cf1c52daad6c07799d308c8a9f73e3 (bug tag was missing in the commit).

Alright, finally supported by gpgme (fot 1.24) For testing you may use

This is not on any workboard. But I tested it with 4win-Beta-64 and the error shown in Kleopatra is now "Unusable public key".
So I'll put it on vsd33.

Indeed, gpg fixes a long standing bug in that expired trusted-keys were not correctly handled. Thus this error message

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.