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.

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.

What happens if you call gpgtar with --utf8-strings --cms additionally to the other options? And what happens if you pipe the archive to gpgtar's stdin?

Right. I think this task inherited the assignee from its parent task.

It could have been discussed whether this makes sense. However, we can't change it anymore because it would change the behaviour. Consider a cron job which looks into a directory with keyids and imports them from a keyserver. It is totally fine if the script returns success if no keys are available.

I have also not found a straightforward way to correct a cross-signature that was made with a weak digest algorithm using GnuPG.

Oh wow. It seems you have already coded the feature request. I didn't want to generate work for you and offered to submit a patch. Not that I am complaining.;-) Thank you!