Thank you for your quick testing.

The patch worked, thank you very much.

Thank you. Tested locally that it does what it is supposed to do and all tests passed for me as expected.

@werner: thanks, with the 'pcsc-shared' option it works for me (after sending SIGHUP to scdaemon, of course). So, do I understand correctly that this cannot be the default?

The patch worked, thank you very much.

Use the source! GnuPG is free software.

Thank you for the log.

Here is the log file requested.

Here is the change remained:

diff --git a/src/fips.c b/src/fips.c
index bcadc5f2..5499aee8 100644
--- a/src/fips.c
+++ b/src/fips.c
@@ -82,6 +82,12 @@ static void fips_new_state (enum module_states new_state);

Before rebasing, I pushed a change to simplify access to no_secure_memory variable by rC209d98dcf66b: Simplify the logic for no_secure_memory..

I tested the change of last_update after importing a same key with different content, but found that there is still no change.

So, please show us gpg-error-config-test.log by your build.

On import. Please use gnupg-devel mailing list for further API questions. This is a bug tracker and not a help forum.

A clumsy workaround for the Kleo bug is to put "keyserver ldap:///" into the global gpg.conf after an ignore section containing keyserver. This will let gpgconf emit "ldap:///" unless a local gpg.conf exists.

Thanks. If I'm reading correctly, that fix was pushed in July. Any idea when the next release might come out?

Thank you for your report.

Adding comments, fixing "const" qualifier, I pushed the change.

A patch created:

GnuPG 2.2 does:

• In g10/sign.c:do_sign, it keeps leading zeros for Ed25519 signature, as opaque MPI
• In g10/build-packet.c:do_signature which calls gpg_mpi_write to output the (opaque) MPI, leading zeros are removed.

Let me explain concretely.

Excuse me NIBE san. What if any action do you expect me to take on this matter?
__outer

For GnuPG 2.2, it's better to be conservative (least change of behavior, if any).

Thank you, applied.

Thank you. My local tests (in emulated fips mode and normal mode) do not show any errors with current master branch.

Hi guys, I just tested the git version (426d82fcf1c133bfc1d5c931109d71db3f3815a9) and it works well thank you.

And please let me know the change rC751fcadd34ed: random: Release memory in DRBG. affects t-secmem failure.

IIUC, one of the causes for the failure of secmem was resource release of DRBG memory.

Thank you for testing.

Applied. Thank you.

Fixed in 2.2.33.

Thanks. I did some git archeology and found the first mention of this in the following commit in 2011 without much details:

Adding the case for == 0 only might be problematic, because I don't think it's an alias for a secure value; I think that == 0 means that it's up to libgcrypt to select the value (just like other generate_* functions).

There is a "sharing violatation", error which means another process got access to the card. You can try to put

Let me get back to this once more as one of the parts for RSA was initially missed:

diff -up libgcrypt-1.8.4/cipher/rsa.c.fips-keygen libgcrypt-1.8.4/cipher/rsa.c
--- libgcrypt-1.8.4/cipher/rsa.c.fips-keygen	2017-11-23 19:16:58.000000000 +0100
+++ libgcrypt-1.8.4/cipher/rsa.c	2019-02-12 14:29:25.630513971 +0100
@@ -696,7 +696,7 @@ generate_x931 (RSA_secret_key *sk, unsig

I did go through a bit more testing too and the selftests still initialize and use the secure memory (and the t-secmem fails in FIPS mode if we invoke selftests from constructor). Now from run_random_selftests() -> _gcry_random_selftest() -> drbg_healthcheck() -> _gcry_rngdrbg_healthcheck_one(). So this means that we either need to de-initialize secure memory after the constructor selftests or prevent its initialization as I suggested in some of the previous comments.

What would be setting those? And how do I disable it?

It does have them defined!

$ gpg-connect-agent "getinfo getenv COLUMNS" /bye
D 80
OK
$ gpg-connect-agent "getinfo getenv LINES" /bye
D 24
OK

What would be setting those? And how do I disable it?

A possibility is that gpg-agent which invokes pinentry happens have COLUMNS and LINES defined, then, pinentry misbehaves.

Thanks again for further information.

Hmm, I added that to my formula, and see ncurses 6.3 now, however the issue still occurs.

dyld[20991]: <55AFFB3D-2011-35CC-9486-B30BC1CA12F7> /opt/homebrew/Cellar/pinentry/1.2.0/bin/pinentry-curses
dyld[20991]: <AAD35EC9-FC8A-3ED4-A829-C59E710CEA8A> /opt/homebrew/Cellar/libassuan/2.5.5/lib/libassuan.0.dylib
dyld[20991]: <59683137-0511-3681-8BA6-04A78592B197> /opt/homebrew/Cellar/libgpg-error/1.43/lib/libgpg-error.0.dylib
dyld[20991]: <A9DA1A80-D101-339B-9637-85A65285E050> /opt/homebrew/Cellar/ncurses/6.3/lib/libncursesw.6.dylib
dyld[20991]: <679CDB15-D472-38E8-8840-B38874010D51> /usr/lib/libSystem.B.dylib
dyld[20991]: <BB47A721-69A7-3EEA-9D9B-82F88FFF2641> /usr/lib/system/libcache.dylib
dyld[20991]: <E6CCD148-5E91-3111-BE37-1C19402F4637> /usr/lib/system/libcommonCrypto.dylib
dyld[20991]: <92001FF7-799E-3BA8-BF46-5FA01FFB952C> /usr/lib/system/libcompiler_rt.dylib
dyld[20991]: <6BE94DC2-F363-3D76-B056-F45D4B56E152> /usr/lib/system/libcopyfile.dylib
dyld[20991]: <881973B2-0426-325F-8D1A-17D60AE0CBFA> /usr/lib/system/libcorecrypto.dylib
dyld[20991]: <9C4116F5-B8EB-3A00-B4B5-54AF6A76F66B> /usr/lib/system/libdispatch.dylib
dyld[20991]: <96ECED73-F10C-3941-91A7-00254B907499> /usr/lib/system/libdyld.dylib
dyld[20991]: <F7CDC52B-7961-3283-A30F-B06E2E6ED6AB> /usr/lib/system/libkeymgr.dylib
dyld[20991]: <8D2BECEF-1038-3F2C-B8EF-B02C03092286> /usr/lib/system/libmacho.dylib
dyld[20991]: <3D861651-91A7-3D78-B43B-ECAA41D63D9E> /usr/lib/system/libquarantine.dylib
dyld[20991]: <FA2D8F89-D9C4-316F-9FDC-BFF1A791BD4E> /usr/lib/system/libremovefile.dylib
dyld[20991]: <61963381-E322-3D0F-855D-CE1EA31FA4E1> /usr/lib/system/libsystem_asl.dylib
dyld[20991]: <770FEB1F-FE27-3670-810F-A063D281CC8D> /usr/lib/system/libsystem_blocks.dylib
dyld[20991]: <660D7866-E2A2-3651-A0A5-806E9217736B> /usr/lib/system/libsystem_c.dylib
dyld[20991]: <1F580793-A1C3-30C6-A9BC-7789C14677AE> /usr/lib/system/libsystem_collections.dylib
dyld[20991]: <8370E8A5-EADF-3A2C-9D5B-CA148723A5CA> /usr/lib/system/libsystem_configuration.dylib
dyld[20991]: <30C492F6-C9E6-3C1D-BE52-CA4F4FC824D6> /usr/lib/system/libsystem_containermanager.dylib
dyld[20991]: <F2A34B01-C264-3B7E-B3C9-1671E9E3C185> /usr/lib/system/libsystem_coreservices.dylib
dyld[20991]: <01C0D793-E5FB-3141-95D6-32A973F9FFF8> /usr/lib/system/libsystem_darwin.dylib
dyld[20991]: <AED9DAFC-7AB1-31CF-96A1-14C87B614DD3> /usr/lib/system/libsystem_dnssd.dylib
dyld[20991]: <F0456F65-B4DF-3E14-91DC-C0C2A7954233> /usr/lib/system/libsystem_featureflags.dylib
dyld[20991]: <5E36F087-5EF7-33B7-ACDA-CAE1C4A97621> /usr/lib/system/libsystem_info.dylib
dyld[20991]: <6AB180A4-1D1E-3FA1-88B7-A7866EFACFC8> /usr/lib/system/libsystem_m.dylib
dyld[20991]: <7C9F7726-62C1-3B03-8130-03E8A2A68DDF> /usr/lib/system/libsystem_malloc.dylib
dyld[20991]: <2F331637-80F6-3208-816F-618DA9081899> /usr/lib/system/libsystem_networkextension.dylib
dyld[20991]: <3701D756-7023-30C0-9A36-852971092AA9> /usr/lib/system/libsystem_notify.dylib
dyld[20991]: <4234FAEC-7D18-30E7-AEAD-E9FB6922AFE9> /usr/lib/system/libsystem_product_info_filter.dylib
dyld[20991]: <1214F568-24BF-379F-8A86-FF947EE5F18A> /usr/lib/system/libsystem_sandbox.dylib
dyld[20991]: <49553CC1-66C3-32B1-91C6-4415DE230F58> /usr/lib/system/libsystem_secinit.dylib
dyld[20991]: <17550B77-D255-389A-B779-906AF75314B6> /usr/lib/system/libsystem_kernel.dylib
dyld[20991]: <8B28F7A3-6681-3D34-92AE-3688A74F50E6> /usr/lib/system/libsystem_platform.dylib
dyld[20991]: <AA39FF66-B3F0-3777-99BC-F4A4C5CBD566> /usr/lib/system/libsystem_pthread.dylib
dyld[20991]: <73885FA5-76B6-3AA3-8D91-60B2E0078F99> /usr/lib/system/libsystem_symptoms.dylib
dyld[20991]: <362E885B-20EA-395B-BB01-6E46B864294D> /usr/lib/system/libsystem_trace.dylib
dyld[20991]: <D0A538E3-7A75-395A-993C-A3EA7947F55A> /usr/lib/system/libunwind.dylib
dyld[20991]: <A77B4CE2-0855-3C19-B4A6-47B094CF0DDA> /usr/lib/system/libxpc.dylib
dyld[20991]: <52A50407-CD9B-3A67-A0C2-2D9D6F3043BF> /usr/lib/libc++abi.dylib
dyld[20991]: <8FCA2160-F786-398A-AEAC-2B3D5BD72BB8> /usr/lib/libobjc.A.dylib
dyld[20991]: <6B0DE0DE-0EA2-3948-8B7D-8BA309414B27> /usr/lib/liboah.dylib
dyld[20991]: <20FBE382-CC21-324E-8813-C84B94CC04EF> /usr/lib/libc++.1.dylib
dyld[20991]: <A714AC09-9E2D-3608-B8C1-D6300E852308> /usr/lib/libiconv.2.dylib
dyld[20991]: <1907D41B-6D4B-3EA0-AD3B-5770431B6327> /usr/lib/libcharset.1.dylib

So, the solution is to build pinentry with newer ncurses. As I wrote in another comment, it's adding a single line to the formula.

The change for pubkey-util.c is not needed any more, because

• T5665 handles new functions rejects use of SHA-1 as approved signature.
• pubkey-util.c is used by gcry_pk_sign and gcry_pk_verify.

Thank you for the info.

I ran DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 DYLD_PRINT_RPATHS=1 pinentry-curses and see libncurses.5.4 (full output below).

Is there some other command I should run to check which curses it's using? I see there's a --debug flag but I'm not sure how to use it.

I think that either of following might be true:
(1) macOS has older ncurses (which doesn't support ioctl well, to get columns/lines info) in system
(2) macOS has BSD curses (with no suport for ioctl)

I installed it with brew and didn't provide any special options. This is one of the new M1 macs though, so perhaps there is some platform check deep in the install that is getting confused?

Thank you for the information. So, you don't have these environment variables set.

printenv COLUMNS LINES shows no output, however if I echo $COLUMNS $LINES I see 160 48 both before and after the password prompt.

Curses application (of pinentry) get information of screen size by:

• environment variables (COLUMNS, LINES)
• operating system using TIOCGSIZE or TIOCGWINSZ ioctl
• tinfo data base

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

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.

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) :(