FWIW, We have a similar mechanism for the secure memory

Recently, I have encountered many problems in adapting the graphical interface interaction between Yubikey and gnupg. I am thinking about why some settings need to be manually added to some additional settings. I found that there are many such solutions on the Internet. Is there any way that scdaemon can automatically recognize these situations and add appropriate settings.

Things are not that easy. I actually introduced a bug in 2.3.4. Here is a comment from my working copy:

@werner Thank you for the answer. Please advise mailing list address.

For support please use the mailing list and not the bug tracker.

GNUpg version 2.3.4 was installed but did not help

Is there a way to ignore SSL check during connection? This might work. We have internal server for our users only.

That KeyListJob returns keys which have fingerprint NULL is caused by keyservers returning just key IDs instead of fingerprints. The change for T5741: dirmngr does not ask keyservers for fingerprints should fix this. Still keyservers are only guaranteed to return key IDs, so we cannot assume that keys returned by KeyListJob have fingerprints.

Thanks!
I will study it soon.

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