Benchmarking blog post that I linked tested GnuPG in symmetric mode, gpg --symmetric. I think symmetric case is important too from performance point of view, there is tools that use gpg --symmetric as bulk encryption/decryption backend (for example duplicity backup tool). Such encrypted files have tag3 (symmetric-key ESK) packet followed tag18 (encrypted and MDC) packet. Could existence of Tag18 packet in input be used as marker for input being rfc4880 and allow disabling those extra hash contexts? As I understand those hashes should not be needed with rfc4880 input (but I don't know all the historical details).

Breaking the flawless decryption of existing old data is unfortunately a highly controversy topic. Recall the no-more-v3 packet support or the required MDC. It was technically okay and 99.99% of the users didn't even notice it. But some were very vocational.

Yes, it would be convenient to use the same $GNUPGHOME in Git Bash (using /usr/bin/gpg) as in PowerShell / Cmd (using gpg.exe in %PATH%)

% export GPG_TTY=$(tty)

In T5813#154552, @Valodim wrote:

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?

Either way, I hadn't considered this for the WKD relay. I'll look into enabling AES-CBC there, at least for backwards compatibility.

Done by rGc8cd66ae7e60: m4: Update our library m4 files from master.

The change of pinentry-tty rP7f7fd8bcfd74: tty: Fix error return paths and its resource leaks. fixes SEGV, but the problem of your case is that access to the device file (/dev/pts/2 in the case of your log with pinentry-tty) failed.

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.