Pretty outdated, but I add it nevertheless to 2.4
s/gnupg-2.4/po/nl.po: 1320 translated messages, 625 fuzzy translations, 268 untranslated messages.

Pushed the fix: rGbb57c808b2ad: scd:openpgp: Fix PIN pin2hash_if_kdf.

Thank you. Applied by : rM87061c0260bb: gpgme.m4: Set $host correctly always.

Ditto for ksba and assuan.

Done for gpg. Needs to be done for gpgsm.

The gcrypt change works for me. Thanks!

I note that @DemiMarie offered a patch for this over a year ago. It doesn't appear to have had any review. If it's good, maybe apply it? If it's problematic, can we identify the problem?

Thanks, I confirm that this new commit is fixing the issue.

In general, asking an application change is not good. Migrating to pkg-config should be an option (not requirement).
However, it's usually recommended to use libgpg-error when an application is used with libgcrypt/libksba/libassuan.

by all means, please proofread it! thanks for the attention to detail. what was the grammar glitch?

I still spotted a grammar glitch in corrections. Thus if we apply this we need to proofread it.

Thank you for testing. Now, I can see the exact reason by your npth log.
Pushed another change: rPTH75c68399ef3b: Fix previous commit.

Build is still failing even with this commit, here is an extract of npth log:

Just to clarify: I personally think it would be perfectly fine to say that AM_PATH_* is only supported when AM_PATH_GPG_ERROR is also used. Adding an invocation AM_PATH_GPG_ERROR is not a great hassle and alternatively pkg-config/pkgconf exists and works perfectly fine (and is a lot faster).

I noticed this recently too on some boxes. Thanks for the good decription. This support for pkg-config style .pc files for our config scripts seems to be a never ending story. The alternative name for libgpg-error-config does not make it easier.

Thanks for report. I've applied this change to master.

The official GPG binary from "c:\Program Files (x86)\GnuPG\bin\gpg.exe" does not exhibit this problem. I will report it to the msys2 folks.

Yes, it is the msys2 build of gpg, installed using the standard msys2 methods. The pwd in my example was from msys2 zsh.
I reproduced the error running under msys2 zsh and in Powershell.
If I understand your response correctly, you are saying this will not be fixed in gnupg itself? I can report it to the cygwin/msys2 folks of course, if you think that is best. But I still suspect the root cause is in gnupg, probably in homedir.c or the code that makes an absolute path from a relative one.
I will retest with the official gpg4win and let you know the results.

pwd is not a standard Windows command. It is availabe in powershell but there I get

I think so. We did not submit a modules for recertification with these changes, but we do not plan this in close future so you can consider it completed.

Can we close this?

Backported for VSD 3.3 even though the issues only occurred in the Qt 6 build.

Please test with: rPTH01f03a91c9bd: Return a run-time error if npth_rwlock_timedrdlock is not supported.

Could you show us the build log of nPth, please?

Meanwhile version 1.32.2 builds. Greatest change is Python 3.12 instead of 3.11…

Seems it was a kernel / USB bug

Sorry, I meant they do *not* arrive at the web interface, they are not visible to me.

It seems my eMails to gnupg-devel@gnupg.org do reach the list …

I understand the desire for stable behavior, and i agree that a change here might affect verification of existing signatures (and might mean producing signatures that will be misinterpreted by older versions).

This has been implemented and tested to be compatible with PGP - a looong time ago. iirc this was discussed around 1999 but might be only by private mail between the PGP hackers and me. Thus any change now might break PGP - which is still widely used (although mostly for encryption).

Oh yeah the idea to implement aliases is more than 20 years old. I guess it is even older. Thanks.

Thanks for the patch.

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.

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.