GnuPG 2.1 is seriously out of date and long out of support. It's probably full of bugs that have been fixed in the last 5 years since its release. Please do yourself a big favor and update to a supported version of GnuPG 2.2.

As the above commit only references pinentry-tty.c, what's the problem with pinentry-curses? Shall I provide the same log with pinentry-curses?

Yes, this was the correct tty at the time of the generation of this log.

Thank you for your debugging.

In D548#5450, @werner wrote:

I am not sure what all the other ode changes are about. There is no explanation.

I am not sure what all the other ode changes are about. There is no explanation.

disk full. Fixed. Thanks.

Manual retrieval of missing certification keys is now possible from the Certifications dialog.

I killed gpg-agent after the config change / before running gpg again. That should be enough to pick-up the config change, correct? In the mean time the system in question was rebooted. Here the full log /with key related stuff redacted).

Strange. pinentry-tty has no place to report ENOENT. I wonder if you notified gpg-agent when you change the config (like gpgconf --reload gpg-agent).

gpg4win_spkgs is used for building the stuff for gpg4win, i.e. for Windows. Are you sure you need/want ntbtls for the Windows build?

This and some other issues with draft encryption are now fixed in master and need a release of GpgOL.

We now autoselect the key.

Why not simply cast to uintmax_t ? That makes the string easier to read.

Might be an issue with matching ciphersuites? There was a problem with this before when GnuPG didn't support AES-GCM yet (https://dev.gnupg.org/T4597). That was added in 2020, maybe it's not rolled out far enough yet?

GPG_TTY in my tests from which I generated the logs above is set to /dev/pts/1 (which is what "tty" returns, what exists in the FS, and what is writable to the user which performs the test).

The string 'Pinentry' is a module name, which is defined in libgpg-error.
It means, the error source is pinentry.

it will be but we first prefer to do some final tests with that version. Feel free to also test. Either this or the next micro version will eventually be announced.

@gniibe Thanks a bunch for the quick fix!

Hi there, is this the new stable version of libgcrypt? Apologies if this is the wrong place to ask; I just couldn’t find any other release announcement for 1.10.0.

After further testing: The error does not occur if WKD is implemented directly under the respective domain.
The behavior of GnuPG differs between Windows and other platforms. However, it is not clear to me which version is behaving incorrectly. But it seems clear that there is no compatibility with the instructions at https://keys.openpgp.org/about/usage#wkd-as-a-service under Windows. (However this may concern another project.)

The server in the testcase is wkd.keys.openpgp.org which is referred with CNAME via the DNS. Referring to https://www.ssllabs.com/ssltest/analyze.html?d=wkd.keys.openpgp.org it shoud support TLS 1.2

Check that the server does not prohibit TLS 1.2 - a few server admins allow only TLS 1.3 for whatever security threats they have in mind.