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.

Last week:

• Learn about VS-Desktop a bit
• For myself, build&install libkleo & kleopatra to see the features
• created pam_authproto-2022-09-20.tgz
• scute

This week:

• scute merging
• libgcrypt master and use of (unintended) variable length array

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 / gdb / etc.

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

• Yes, gpgrt release please.

Last week:

• Minor fixes
  • libgcrypt
  • libgpg-error
  • gnupg
  • gpgme
• T6200
• T6204
• T5862
  • Mostly done. Remaining thing is how/where to distribute pam-authproto module

This week:

• Scute T6002 -> master

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

• Next week: September 19th - not available

Last week:

• T6193
  • Learn gentoo activity for clang 15 + musl c library
  • Then, pushes fixes for Clang 15
• Created T6191: FIPS: Supporting running FIPS enabled machine
• gpgme: Fixed T6187
• T5862
  • gpg-auth is ready for use with xsecurelock
  • test with authproto of xsecurelock with pam-authproto.so (which is similar to pam_exec.so, but supports pam->conv better)

This week:

• Provide pam-authproto.so as Debian package, possibly, extending libpam-modules

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

Last week:

• libassuan: T6170: libassuan: Drop WindowsCE support
• gnupg: Update Japanese translations
• gpg-auth: a tool under gnupg/tools
  • now, it works with xsecurelock
    • See T5862 for usage

This week:

• gpg-auth handling more use cases
  • card with pinpad card reader
  • error cases, like no token available
  • login authentication with pam-exec
• semihosted environment building
  • see how make check works for Windows target on GNU/Linux using Wine