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!

Those options where originally intended for debugging but your suggestion makes sense. I also add this to most other tools.

Removing gpgrt because we meanwhile have full utf-8 support there.

Closing due to age and because gpg4win 4 started to using the much improved GnuPG 2.4

The solution seems to be a newer libccid version. If that is the case we may want to include the fix also in our own ccid driver.

Got this from my card vendor. Sonoma had a buggy CCID driver; compile one yourself and the bug's gone: https://forums.developer.apple.com/forums/thread/732091?answerId=768462022#768462022

Since there are some files that would simply have to be created each time under $GNUPGHOME, I've been thinking a bit more about what sort of approach to take for "fallbacks."

No, I am not aware. I can't remember whether PGP once had such a bug because @dshaw did most cross-testing and fixing for PGP bugs. I would suggest to remove any such checks. IIRC, this was introduced by PGP 2 to speed up signature checking. 30 years ago RSA operations were quite expensive.

That is simply because your XDG_RUNTIME is set to the same directory gnupg uses. See gnupg/common/homedir.c:_gnupg_socketdir_internal

Funnily enough, runtime sockets already adhere to the XDGBDS somewhat by using $XDG_RUNTIME_DIR/gnupg as their path, while everything else uses strictly $GNUPGHOME or ~/.gnupg with no other alternative. Of course, I completely understand that the priority for this is rather low, but I am still happy to look into providing a patch myself that would add these fallbacks if it would help expedite the whole process.

In master, I applied changes for include files which don't harm current target of MinGW-64.

This is referenced from https://nvd.nist.gov/vuln/detail/CVE-2022-3219 for CVE-2022-3219. Can this please be fixed?

I think we can close this issue. Ikloecker explained why. The hint comes from the help files and I think at the time I opened the issue I did not use the help messages.

Ingo, I concede it might be considered a bug on Request Tracker that it does not allow to specify the key as a fingerprint (or calculates it automatically from the email instead of relying on gpg doing it), but you generally want to keep expired keys around for decryption.

Quite frankly, if a third party application calls gpg with anything other than fingerprints to specify keys it's asking for trouble. I have changed KMail from using user IDs to using fingerprints when calling gpg more than 20 years ago.

Sorry, Werner, but I have to disagree on this. Specifying them by fingerprint only works if you have a specific field for the key (including the case where you are just it on the config file).

Instead of tweaking this and risk a regression for some users I added a suggested to the man page to use a fingerprint.

Unfortunately there are real world applications which make use of this option in special environments. Thus we can't remove it. I improved the warning in the man page.

There will be a 2.2.43 soonish. Thanks for the patch.

Thanks. Applied to 2.4 will eventually be merged into master.

This was reported again 3 years later as T4704, and finally fixed in gnupg-2.4.4, released last week.

Thanks! We will try this out and update you with the results.

Since 2.2.20 we had these items in the NEWS

Fixed in GnuPG 2.4.4.

I upgraded to gnupg 1.4.4 now, the problem is gone. Thanks for working.

Thanks @gniibe and everybody!

Fixed in GnuPG 2.4.4.

In T6481#181779, @gniibe wrote:

Arch Linux: https://gitlab.archlinux.org/archlinux/packaging/packages/gnupg
FreeBSD: https://cgit.freebsd.org/ports/tree/security/gnupg

I don't see the patch is applied. Please wait for GnuPG release 2.4.4.

Indeed, openSUSE has applied the patch: https://build.opensuse.org/package/show/openSUSE%3AFactory/gpg2

Arch Linux: https://gitlab.archlinux.org/archlinux/packaging/packages/gnupg
FreeBSD: https://cgit.freebsd.org/ports/tree/security/gnupg

Works as expected on openSUSE Tumbleweed with gpg2-2.4.3-4.2.x86_64:

$ gpg2 --version
gpg (GnuPG) 2.4.3
libgcrypt 1.10.3
[...]

In T6481#181724, @gniibe wrote:

i still observe the same behavior:

What do you mean? I can't replicate the behavior described by you, using the GnuPG from the repo, or the one of Debian 2.4.3-2.

i still observe the same behavior:

In T6481#171399, @gniibe wrote:

• It is also possible for GnuPG to keep the behavior of 2.4.0, so that it doesn't confuse EasyPG.
  • This is a possible solution #2: change in master: rG2f872fa68c65: gpg: Report BEGIN_* status before examining the input.
  • But... it is difficult for implementation of GnuPG to guarantee this kind of behavior.

For a while, distributions can apply rG2f872fa68c65 for 2.4 series.

I do not think this is a very common usecase. For me regarding CMS file operations it would be more important to implement T2435: gpgsm combined sign and encrypt which I find the most annyoing issue regarding CMS file encryption.