No, if you then find out that you cant reach anyone in the protocol you should be able to get back.

Yes I have pcsc-shared in my scdaemon.conf.
I've just tried removing both pcsc-shared and disable-application piv and PIN caching worked as expected.

Are you using PC/SC shared mode? If so, it may be the case of T7041.

I just wanted to report that I'm having this issue on Fedora 39, with GnuPG version 2.4.4.
I'm being asked for the PIN for every operation (Sign, Decrypt, Authenticate) I'm having this issue on 2 different laptops using YubiKey 5C NFC and YubiKey 5C Nano (Firmware version: 5.4.3).
I tried disabling PIV (disable-application piv) and then PIN caching started working again, so I just wanted to report this as it's marked as resolved.

Here comes a new test key along with its 3 secret parts (one for the primary and two for the composite Kyber subkey).

Backported to VSD 3.2

I think it would be the most logical solution to always clear the recipients after a switch of protocol. No restoration for other recipients necessary from my point of view.

So you want the other recipients to be cleared? What shall happen if the user switches the protocol again? Shall the previously selected other recipients be restored?

I like the suggestion to add a checkbox for the upload. That's also in line with certification which is very similar to revocation.

Well I expect to not get an error if I click on something which might be an unusual use case but is a valid operation.
I do not want Kleopatra to select an appropriate certificate, I expect it to not suggest any certificate for the recipients.

For your own certificates Kleopatra knows what to look for when you switch the protocol: Some suitable certificate with the correct protocol belonging to the user. In fact, Kleopatra remembers the last used own sign and encrypt certificates for both protocols.

@mwalle Thank you for your testing.
Applied to master.
After testing, I'll also apply to 2.4 branch.

FWIW, I've tested this patch and it works fine with both KDF as a constructed tag and as a primitive tag.

may be related to https://dev.gnupg.org/T5957#163468

I'm considering applying the following patch. With this change, scdaemon will works well with a card implementation which consider F9 (wrongly) as primitive data object, as well as correct card implementation.

diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 26ac91ea2..09223ce33 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -410,6 +410,10 @@ get_cached_data (app_t app, int tag,
   size_t len;
   struct cache_s *c;
   int exmode;
+  int do_constructed = 0;
+
+  if ((tag < 0x0100 && (tag & 0x20)) || (tag >= 0x0100 && (tag & 0x2000)))
+    do_constructed = 1;

API which does not require allocation internally would be better. In this case, it is allocated on stack by the caller.

I mean, something like this (for GNU/Linux):

diff --git a/src/misc.c b/src/misc.c
index 4db2d9a4..74864334 100644
--- a/src/misc.c
+++ b/src/misc.c
@@ -577,3 +577,80 @@ _gcry_divide_by_zero (void)
     gpg_err_set_errno (EDOM);
     _gcry_fatal_error (gpg_err_code_from_errno (errno), "divide by zero");
 }
+
+#ifdef HAVE_CLOCK_GETTIME
+#include <time.h>
+# if defined(CLOCK_THREAD_CPUTIME_ID) && defined(CLOCK_TAI)
+struct gcry_timedwait
+{
+  struct timespec ts;
+};
+
+typedef struct gcry_timedwait *gcry_timedwait_t;
+
+gcry_err_code_t
+_gcry_timedwait_new (gcry_timedwait_t *r_tw, unsigned int flags)
+{
+  gcry_err_code_t err;
+  gcry_timedwait_t tw;
+
+  *r_tw = NULL;
+
+  /* Possibly, it would be good to be able to select the wall clock.
+   * For now, it's CPU time by the thread.  */
+  if (flags != 0)
+    return GPG_ERR_INV_ARG;
+
+  tw = xtrymalloc (sizeof (gcry_timedwait_t));
+  if (!tw)
+    return gpg_err_code_from_syserror ();
+
+  if (clock_gettime (CLOCK_THREAD_CPUTIME_ID, &tw->ts) < 0)
+    {
+      err = gpg_err_code_from_syserror ();
+      xfree (tw);
+      return err;
+    }
+
+  *r_tw = tw;
+  return 0;
+}
+
+gcry_err_code_t
+_gcry_timedwait_release (gcry_timedwait_t tw, struct timespec ts_r)
+{
+  gcry_err_code_t err;
+  struct timespec ts;
+  u32 negative;
+
+  if (clock_gettime (CLOCK_THREAD_CPUTIME_ID, &ts) < 0)
+    {
+      err = gpg_err_code_from_syserror ();
+      xfree (tw);
+      return err;
+    }
+
+  ts.tv_sec -= tw->ts.tv_sec;
+  ts.tv_nsec -= tw->ts.tv_nsec;
+  negative = ((u32)ts.tv_nsec) >> 31;
+  ts.tv_sec -= negative;
+  ts.tv_nsec += (1000000000 * negative);
+
+  xfree (tw);
+
+  ts_r.tv_sec -= ts.tv_sec;
+  ts_r.tv_nsec -= ts.tv_nsec;
+  negative = ((u32)ts_r.tv_nsec) >> 31;
+  ts_r.tv_sec -= negative;
+  ts_r.tv_nsec += (1000000000 * negative);
+
+  if (ts_r.tv_sec < 0)
+    return GPG_ERR_TIME_CONFLICT;
+
+  if (clock_nanosleep (CLOCK_TAI, 0, &ts_r, &ts_r))
+    return gpg_err_code_from_syserror ();
+
+  return 0;
+}
+# endif
+#endif

Wit the test keys posted in T7014 it is now possible to decrypt the sample data. The test data has been slightly adjusted for the new format; see

This is a KDE bug and not really appropriate for this tracker.

Alexander suggested that we could avoid another window by putting check boxes in the revocation window for automatically uploading to the configured keyserver and creating a public key export with the revocation. That could then be configurable via the registry on windows, so that companies could adapt that according to their SOP.

In T6813#184976, @ebo wrote:

Works on Gpg4win 4.3.1, too.

But noticed an inconsistency for the key creation via GpgOL: Contrary to the behavior for key creation in Kleopatra in Gpg4win, you are asked for a password for the new key.

Works on Gpg4win 4.3.1, too.