The original intention was to fix t-poll failure on Windows.
It was fixed in different way in rE858bcd4343ac: tests,w32: Use CreatePipe and es_sysopen..

When the device-side feature was proposed, I had suggested to extend the protocol so that host side can know device side requires user interaction and prompt a user. But... the result was "it can be done with device side only".

Caveat, Caveat (Warning, Warning) I know I've been quite busy with other activities, and ITMT my client status went really bad and even worse reached its final point and self-rebooted while I was trying to suspend it, but anyway this update is needed because I just discovered that my last choice to prepend %ProgramFiles(x86)%\Gpg4win\bin;%ProgramFiles(x86)%\GnuPG\bin;%PATH% was not very good. Why ? Simple, as I discovered today (few hours ago) using this syntax, will only be valid&useful only if you really want to restrict Gpg4win v3.1.16 usage only to accounts in Administrators group.
Ok, so now you're wondering: How I discovered this effect ? Again simple, desktop shortcut that I have for starting new 'Command Prompt' was modified to always run as Admin, so I have to specifically choose when I want to run it without Admin privileges, and so today, after I didn't notice I had launched Kleopatra before, right after closing it, I launched a new Command Prompt and so when I tried to run 'gpgconf --kill gpg-agent' I only received this answer :

'gpgconf' is not recognized as an internal or external command,
operable program or batch file.

So then I obviously opened another 'Command Prompt' as an Admin and correctly killed gpg-agent so ensuring that everything was indeed still working as expected.
So now you're asking, why in the past I had confirmed that prepending those paths I was expecting to work, really worked ?
If you remember well how I reported Iìve done my past installations and tests, I also made those changes in OS System Environment Variables really on the fly and then just re-confirmed they were valid via GUI by simply pressing [ OK ].
And so this is the test I just repeated again and so I can re-confirm you that only after by doing so, every new 'Command Prompt' started as non Admin user will have proper access to those newly prepended paths.
Otherwise, those paths will work only for any new 'Command Prompt' if run with an account in Administrators group.
So while this can still be temporarily fine for me, I'm unsure it might have been a real standard choice for Gpg4win v3.1.16 setup run without experiencing the error I'm reporting in this bug, so please just ensure to avoid using %ProgramFiles(x86)%\Gpg4win\bin;%ProgramFiles(x86)%\GnuPG\bin; syntax when changing your paths on the fly by prepending it or appending to %PATH% even if you should try to definitely solve same error I found and reported with this bug. OK ?
Thanks for your attention (for now).

I do not like the idea of using the get_config interface for this. It should be easily usable by applications to check for single cipher/mode so int/bool return values would be preferred against the string ones (which are now used in the get_config). I am not sure if getting all the configuration in one string blob would be any use (except for some auditing) either.

Thanks for the help. After running make clean / aclocal / autoconf / autoupdate … &etc, the patch worked & make check passed all eleven 11 tests, ie the new 12th test was not performed.

Right, but SHA-256 have higher time consuption, which is always good in password stretching. Current notebooks hit maximum value for s2k_count:
$ gpg-connect-agent 'GETINFO s2k_count' /bye
D 105682944

Sorry, we won't do that. Actually SHA-1 is still allowed when used in a KDF mechanism like S2K. OpenPGp is about Public Key cryptography and for that it is important to keep the keys safe. Protection the private key with a passaord is a failstop scheme which gives time to revoke the actual key and handle the compromise. When suing symmtric encryption (gpg -c) ist is strongly sutested to use a password with at least 128 bit entropy (e.g. by using our magic wand button). The S2K iteration is actually not needed in such a case.

Thank you for your log.

Here is ”config.log", or did you want just the screen output?

Please show us the log of configure, not just the result of the failure.

I’m not that geeky anymore.

If you see wrong result for the decision of the HAVE_LOCK_OPTIMIZATION (for running the test), it's better to contribute to gnulib (https://www.gnu.org/software/gnulib/) for the detection of thread features.

I've just confirmed that the fixes in the commit "rE50e0f32b1935" above to configure.ca & tests/makefile.am do NOT fix the problem under MacOSX Catalina 10.15.7 using Xcode 12.4, gcc Apple clang-1200.0.32.28.

I'm getting the same error even when compiling with x86_64/glibc (from Apple clang-1200.0.32.28) :(

Not a bug but a limitation of 2.2's option listing: In contrast to 2.3 we can't *show* the used options via gpgconf correcly if there is a conflict between global and local options. However, the actually *used* values are different and correct according to the config. In particular a global forced option overrides any local or command line option.

We should only allow this for v5. This way we get incentive to move forward. ed448 requires a newer version anyway and thus it is good to take this as an opportunity to also demand AEAD etc.

The branch gniibe/v5/448 has the implementation.

To be conservative, given the situation most implementations already support zero-removal and zero-recovery, it's better to output zero-removed signature, that is, signature with well-formed MPI.

My proposal is applying SOS (MPI with leading zero octets) patches, for 2.2, because there may be existing keys with SOS already.

It's not yet solved.

Reading the documentation of musl, it seems that there are no equivalent feature which detects if an application is single-threaded or not.

In the libgpg-error implementation, it may skip synchronization when it can detect an application is single threaded. The t-lock-single-thread test checks if it really skips as intended.