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

Fixed in 2.4.4.

Was anything done here apart from en-/decoding filenames to/from UTF-8 on Windows?

Brainpool Cert on Disk is not relevant. Disable backup function for this case.

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

Most things are done. Missing stuff

Alright: We have support for all our combined algos ky{768,1024}_bp{256,384,512}and ky{768,1024}_cv{25519,448} as well as test keys and encrypted test messages.

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

Applied to 2.4 branch.

Applied to 2.4 branch.

Nobody uses gpgtar for S/MIME

What is the current status of this issue?

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

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

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

@werner I- think you were a bit quick on the trigger to shut this down.
I had rebooted the machine in between attempts. So your analysis is actually not correct.
Basically you have an issue that something in gpg is using something in a locale that is not installed. I pretty much proved that.
Anywho, I'll leave it to you to work out if you want to bother investigating it properly.

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

The following patch works.

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.

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.