In T4977: dirmngr not working with linux kernel parameter ipv6.disable=1, EAFNOSUPPORT fix was applied in 2.2.22.
I think that original problem in this report is fixed.
Please test with 2.2.22.

Actually, configure already has the check.
If it's really needed to build without zlib, you can use this patch:

From 76920ac034490e4860ad6abe9891e3b1c0813363 Mon Sep 17 00:00:00 2001
From: NIIBE Yutaka <gniibe@fsij.org>
Date: Fri, 28 Aug 2020 11:02:13 +0900
Subject: [PATCH] Until compression is implemented, build with no ZLIB can be
 done.

Thanks. Applied to 2.2 and master.

Was easier to fix than expected. Thanks for the report. Fix goes into 2.2.22.

[These damned typos in commit messages ;-)]

The keyserver options control how gpg imports or exports keys to the keyservers. Thus they indeed belong into gpg.conf.

I have a couple of keyserver-options statements in there, but no keyserver statement. Should the options be located in the dirmngr.conf file instead?

I guess you have a keyserver statement in your gpg.conf.
By using

What is the current encoding? OEMCP ?

So if gnupg version >= 2.2.22 Kleopatra needs to convert the passed filenames to UTF-8 and pass them with the --utf8-strings option to gpgtar. This needs to be changed in Kleo. -> Assigned to me.

Done for master and 2.2.22 - libgpg-error 1.39 (not yet released) is required for the actual fix.

Fixed for 2.2.22

Thanks for reporting. Fixed for 2.2.22. repeat==0 works like before and repeat>1 also (that is several passphrase pinentries will pop up).

Thinking about the logic from an email application viewpoint:
To display what will happen, I want to know if I can encrypt to an email address and what trust level I have in the public key I'll find.

I am the worst. I totally forgot about this.

No more information, can't proceed, thus, closed.

If you use

Just reading this issue in detail.

It is indeed a limitation. We added these options to support the Kleopatra GUI. To avoid problems with filenames with embedded newlines etc. Kleoptra uses a binary nuls to delimit filenames. And that is what we only support.

I believe the problem here is OS X 10.12's (and above) System Integrity Protection (SIP). SIP protects system integrity by doing things like sanitizing environmental variables for system programs. Sanitizing environmental variables on system programs avoids code injections.

@JW: @gniibe explained you the problem and provided a fix (i.e. use correct specifiction of the directory names). Changes to Makefile.in are a no-go because that is a built file and a real fix would need to go into libtool. However, for a couple of reasons we do not want to update libtool (e.g. too many breakages in the past, we have out own fixes in for Windows). Thus we consider this bug closed.

I understand your point, but your fix is not relevant

Thanks for your patch. I understand your point, but your fix is not relevant (for supporting all platforms). You can use that way in your build script, but we can't take that approach; The correct fix is fixing libtool.

I'm feeling difficulty to talk to you.

@JW, I'm feeling difficulty to talk to you.

... no-support of slash at the end of path and duplicated slash, we won't fix.

T5024: libtool problem for some platforms for 'make check' (program built with -no-install won't work without installation)

For the original problem of no-support of slash at the end of path and duplicated slash, we won't fix.

@JW, I'm afraid you are not able to read what I write here. This is not chat system at all. For chat system, please use XMPP on
gnupg-devel@chat.gnupg.org as written at https://gnupg.org/documentation/mailing-lists.html (if possible).

I wrote that "FAIL: gpg-error-config-test.sh" is because of your typo

I wrote that "FAIL: gpg-error-config-test.sh" is because of your typo, and I asked to fix your typo and test again.

... you are now describing another problem

@JW, you are now describing another problem, instead of the problem you reported.
I'm closing this one.

Awesome. Thank you for the explanation and for solving the issue.

Thanks a lot.

Fix will be in 2.2.22. Thanks for the report.

It was actually moved to noninstall in 2006. The reason or this is a conflict between the version of gpgsplit in GnuPG 1.4 and 2.0. Back then it seemed easier to keep on using the gpgpslit from 1.4 because that version was installed anyway. At that time gpg was called gpg2 we changed this much later and probably forgot to switch also to the gpgsplit from GnuPG 2.

You used --personal-digest-preferences to force the use of SHA-512, right?

Do you mean you want to copy a backup key created while generating the keys for the card onto a new card?

The problem appears to be the test framework is not setting a LD_LIBRARY_PATH (or DYNLD_LIBRARY_PATH on OS X).

As far as I know, the environment is set correctly. PKG_CONFIG_PATH, --prefix and --libdir are set. And runpaths are also set.

I meant:

If you can point me to a commit, I can patch the package and retest it.

If there is no other problem (than the issues of additional slash and double slash), I'll close this bug report.

Solved in master (1.9). We won't do it in 1.8.

Use

gpgconf --kill dirmngr

to stop it.

Thank you, Andre. Just updated here, problem fixed.

Thanks Andre,

This has been shipped with Gpg4win-3.1.12

I don't mind if this is marked as resolved. As long as I use my script, the agent works flawlessly with my Nitrokey. The agent startup is very fast. The script also resolves the effect that the agent won't work after the system is waked from sleeping state.

Thanks for providing your workaround.

I'm not sure what to do with the issue. For further analysis we would need to figure out what third party software breaks the MIME structure of the mail. That is more something for a support contract and not for the general issue tracker. This issue is very specific to your setup and so I'm not surprised that Microsoft says it can't help.

We have released 3.1.12 which updated all the GUI libraries Kleopatra uses and I got some feedback in related issues like T4689 that this might have helped.

3.1.12 was released with this.

I just ran the test suite ~10 Times with -j48 on a 12 core machine and cannot reproduce this at all with GnuPG-2.2.21 and gpgme-1.14.0 so I tend to put this on resolved, otherwise this is a candidate for an issue that will be indefinetly in the tracker which we cannot reproduce or analyze further.

The t-json failure is: T4820

Thanks, I've applied this with an explicit include to <cstdlib> it was not required on Linux and Windows but I think it's better not to rely on internal libc++ include chains.

@bzbue1 Thanks for the info.

I'm afraid that the dynamic linker doesn't allow hardcoding library path in an executable on macOS.
(It is only supported on some limited platforms.)

I can no longer reproduce this in Gpg4win-3.1.12.

Thanks for your report.

According to OS X 10.9 man pages for getenv(3) (10.9 is what I have available), the source file editinteractor.cpp should include <stdlib.h>. Since its a c++ source file, I believe the include of interest is <cstdlib>. The man page also says the link library is -lc.

BTW, I learned that Fedora now uses pkgconfig (instead of pkg-config).
https://github.com/pkgconf/pkgconf

Try with --prefix=/home/jwalton/tmp/pk2delete (with no slash at the end) and --libdir=/home/jwalton/tmp/pk2delete/lib64 (with no double slash between pk2delete and lib64, but a single slash).

There are no log file but you can run the test by hand: