Merged the changes in t6002 branch into master.

Applied and pushed the change from @joeyberkovitz in rG3257385378bb: dirmngr: Interrogate LDAP server when base DN specified..

Thank you for your report.

To proceed, I pushed an initial part as rG993820c31521: dirmngr: Factor out interrogate_ldap_dn function., which doesn't change any behavior.
Then, the point of the change will be clearer.

pinentry-emacs is obsolete. It's for older Emacs (<= 25, IIUC) which had lisp/pinentry.el.
For Emacs 26 and newer, you can simply use epa-pinentry-mode having the value of loopback.

That's from my confusion. I'll revert.

Testing gpg-auth : There are two different use cases

• test with xsecurelock for screen lock
• test with pam-autoproto for login / gdm / etc.

Here are pam_authproto.c with Makefile, so that you can compile it with libpam:

@ikloecker Thank you for the pointer.
When people will use C23 compiler, there will be no problem (even with non-fixed version). That's good. :-)

Pushed similar changes for GnuPG and libgcrypt (which are actually harmless as it is internal use, not exposed header).

Pushed the fix.
Note that non-in-tree build never been reliable (using the result of the configure, in tree).
So, I basically don't consider the use case of non-in-tree build.

Reviewing the build process, it's just better to use @...VAR...@ by configure (instead of invoke pkg-config again in setup.py).

Pushed changes.

Note that, we cannot use enum values in CPP constant expression like:

# if GPG_ERR_SOURCE_DEFAULT != GPG_ERR_SOURCE_KEYBOX

That's because CPP has no way to know enum values.

Here is a PAM module, which interact a spawned process using authproto protocol of xsecurelock.

Checking musl internal, it seems that we can detect a single threaded application by:
https://git.musl-libc.org/cgit/musl/tree/src/internal/libc.h#n22

Could you please check what pkg-config --cflags ncurses returns?
In my environment (of Debian), it returns:

Here is a list of possible issues:

Pushed the fix for GPG_ERR_INV_ENGINE.

gpgsm may emit S IMPORT_PROBLEM 1 (with no fingerprint information) when it cannot find valid fingerprint.
I think that this case should be handled correctly by GPGME, not returning GPG_ERR_INV_ENGINE.

It's not yet pushed, because it requires new release of libgpg-error (for T6112: libgpg-error,w32: bidirectional Pipe support for estream).

I encountered this issue of struct stat when compiling for x86_64 of Windows.
I'm considering this patch:

diff --git a/common/sysutils.c b/common/sysutils.c
index c30f9a0ce..bbed309a8 100644
--- a/common/sysutils.c
+++ b/common/sysutils.c
@@ -1237,10 +1237,20 @@ int
 gnupg_stat (const char *name, struct stat *statbuf)
 {
 # ifdef HAVE_W32_SYSTEM
+#  if __MINGW32_MAJOR_VERSION > 3
+    /* mingw.org's MinGW */
+#   define STRUCT_STAT _stat
+#  elif defined(_USE_32BIT_TIME_T)
+    /* MinGW64 for i686 */
+#   define STRUCT_STAT _stat32
+#  else
+    /* MinGW64 for x86_64 */
+#   define STRUCT_STAT _stat64i32
+#  endif
   if (any8bitchar (name))
     {
       wchar_t *wname;
-      struct _stat32 st32;
+      struct STRUCT_STAT st32;
       int ret;