Back in the ancient days we allowed to dlopen algorithms so to avoid patent problems in certain countries.

Thanks! please consider adding it to 2.2 and master as well. I suspect it's more outdated than it would be if it had been shipping in the upstream tarball.

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.

Done for gpg. Needs to be done for gpgsm.

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?

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.

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

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.