Please continue on T7041. This ticket is going to be closed (as the problem described was fixed already).

Okay, fix pushed to master, 2.4, and 2.2. Thanks.

Applied to 2.4 branch.

Applied to 2.4 branch.

• gnupg-2.4.5/tests/asschk.c 2023-04-04 02:28:39.000000000 -0600

+++ gnupg-2.4.5-c23/tests/asschk.c 2024-04-19 21:21:36.460724329 -0600
@@ -656,13 +656,13 @@
static int
eval_boolean (const char *cond)
{

• int true = 1;

+ int tr = 1;

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.

@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.

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;

Applied to master. If no problem will be found, I'll apply to 2.4 branch too.
Let's see.

I guess the agent was still running when you deleted and soon re-created the ~/.gnupg directory. The agent is responsible for the private keys subdir and it did not yet noticed that its homedir (and thie subdir) vanished. Depending on your system the agent should terminate itself after some time in case the homedirectory was deleted. Thus to remove the homedir please use

The following patch works.

Please wait investigating it, a downgrade of the *kernel* from 6.8.2 to 6.8.1 helped. It seemed the USB communication got broken with 6.8.2. I am investigating

I rebooted, edited the scdaemon.conf to match the above, and tried gpg --edit-card with the yubikey plugged in. It resulted in the same output:

For the reference, for now i just did the dummy install in the Fedora spec file:

Please use

Tobias, if you find some time, can you please see how this can be done.

Trying to reach Ralph Seichter via the eMail address he is using failed – Osterferien?

The certificates from the same test smart card work in Version 3.2.2.231170 (Gpg4win-4.3.1), too, but there all certificates are shown, that is one more than in the VSD version. Seems gpg2.4 can handle certificates which 2.2 does not accept. But that is nothing to complain about.

Please keep also in mind that the OpenPGP card specification has always and is still developed along with GnuPG . Thus if there are any uncertainties in the specification GnuPG's way of handling thing is the way to go. If there is a way to chnage things without risking any breakage we can of course fix that. In all other cases we need to continue wit the current way. For larger changes in the spec we can of course cleanup stuff - Achim is currently reworking on a revision.

Please keep in mind, that it is not only about GnuPG and the OpenPGP card, but also between GnuPG and other PGP applications. I'm not really sure what the recent commit is doing, if it only affect the reading or also the writing of the data. But IMHO GnuPG should stick to the standard also if writing the KDF DO data because eventually, it will be used for authentication with the card.

FYI as a VSD customer you have access to support. Please check Help-> about Kleopatra for the infos,

In a current version I see this at least if I do not quit Kleopatra completely and restart to another screen setting. Further testing at the moment is not warranted, as there will be changes to the columns handling with the switch to Qt6. (T6924)

Btw compare the Kleopatra versions in Gpg4win and your VSD Version. They should mostly be identical with VSD maybe lagging a bit behind, Or your emplayer has not updated VSD. Many don't

I cannot think of any of our products where you cannot chose the signing key.

From your description it is not clear what you did exactly.

I assume you mean the information shown in the subkeys window int the column "Strength"?

Given the situation where GnuPG works well with existing OpenPGP card implementations, what we should do here is, perhaps:

There are multiple problems described in your report. Let us handle one by one.

I am still not sure why I noticed the double signing but with the new stamp feature we have an effective way to avoid long delays due to authenticode signing. Some gmake macro guru might want to look at gpg4win.mk.in to get rid of the duplicate rule ignore messages.

strcasecmp is pretty standard on Unix. However, in GnuPG we test for it and mostly use our own ascii_strcasecmp to avoid fun with locales. Ralph Seichter is providing macOS builds for GnuPG (https://sourceforge.net/p/gpgosx/docu/Download/) . Maybe it is worth to contact him via the gnugp-devel mailing list and ask him whether he has experience with your toochain.

By adding "-Wl,-t" to the arguments g++ reported:

Libtool invocation has "--tag=CXX --mode=link /opt/local/bin/g++-mp-7 -std=c++11 -pipe -Os -std=c++17 -D_GLIBCXX_USE_CXX11_ABI=0", but g++ then has no -lstdc++ – in C -lc is automatically used because there all C library functions can be taken from… (same for mathematical functions and -lm)

It seems libtool fails to add the standard C and C++ libraries to the link command line. On Linux I have "[...] -lstdc++ -lm -lc [...]" in the libtool link command line. Looks like a bug in the tooling (macports or libtool).

Thanks, that patch works for me.

And we should also use timestamps for each signed file so that we don't need to re-sign all of them over and over during build process tweaking.

Fixed in master.

The reset was due to running gpg-connect-agent reset /bye. I am currently testing something elese will get back as soon as I can turn back to 2.4

Note that this has also been ported to 2.4 and 2.2 and tested by looking at the status lines.

There are two locks here; (1) rw_lock for card_top (list of cards) access and (2) individual card lock.
It looks for me that:

• don't know how/what the thread 7208.2 does
• the thread 7208.3: KEYINFO, then PKSIGN (gets read lock for card_top, then, individual card lock)
• the thread 7208.4: SERIALNO --all (and wait for write lock for card_top)

Thanks for reporting this. Returning error codes to upper layers is not always easy because the original logic is that we have a global error counter to decide whether an operation succeeded. My fix to check the error code before emitting the DECRYPTION_OKAY status,

handle_plaintext gets data returned by iobuf_read, and does not check the error status of the iobuf object.

But only if you can figure out in a transaction or locked sytate whether the card needs a verify. Otherwise we have a race between changing the PIN and verifying a PIN.