Sorry for resurrecting the done task, but I got a message from @pmgdeb who noticed there is mismatch between parenthesis in the --with-fips-module-version help string. The attached patch fixes the issue and add proper help text.

I have just checked both the installation script, which still installs gpgme-json.exe and the gpg4win-4 installer downloaded from gpg4win.org gpgme-json.exe is properly installed under <instdir>\bin gpgme-json.exe and under bin_64

See T5758. The workaround is not to set a reader-port.

Downgraded the gnupg to 2.2.33 using this installer and I am now able to successfully open the Kleopatra GUI.

Should also note that once the GUI is opened, GnuPG's smartcard deamon (32 bit) transitions to Very high power usage and appears stuck there, consuming a full logical core's worth of CPU time.

And I'm testing following:

The "at first" change done.

At first, I think that we need to change the way how libgcrypt rejects non-approved cipher/md/mac/pk.

Backport done but diligent testing is required.

The debug log was from gpg and not from dirmngr and thus it is not helpful. I also guess that an older dirmngr was still running, because the LE bug has been fixed in 2.3.4.

Will go into 2.3.4.

In T5744#153233, @alexnadtoka wrote:

And --keyserver-options check-cert is removed from new gpg versions (((

Here is log in english

And --keyserver-options check-cert is removed from new gpg versions (((

@werner can you show me tutorial for proper bug submit? I think it is a bug and gpg client on Windows does not support valid LetsEncrypt certificates on keyserver. It does not work with any keys server . Tested few public keyservers as well. ((

We decided to notify the user if the keyserver doesn't return fingerprints. The fingerprints are needed by Kleopatra as unique identifier for keys. Trying to make key lookup work without fingerprints isn't useful.

Please see https://gnupg.org

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