FYI, if you can use backports, GnuPG 2.2 series is available
See : https://backports.debian.org/news/stretch-backports/

Sorry, I looked wrong place. It is balloon_final which assumes user provided RESULT is aligned, which is wrong.

I think that this patch should not be needed, if our implementation of _gcry_private_malloc is not buggy (ensuring same alignment condition as system malloc does).
I just realized that it is buggy unfortunately, so, I'm opening a task for that.

@ikloecker,
Your response makes total sense but our restriction is the OS at the moment. This is the highest version of GPG available on Debian 9 so we cannot upgrade at the moment.

Try gcrypt-devel@gnupg.org, i.e. without the lists subdomain.

Add the following to dirmngr.conf:

debug ipc,dns,network,lookup

There are more debug flags but the above flags should cover anything related to the lookup.

It would be awesome if you could implement this \o/

You may have to restart the dirmngr to see the log-file option be honored. The gpg request to dirmngr should be visible in the log.

In T5813#154705, @bernhard wrote:

@mieth can you enable the dirmngr log and give it more message, you'll be able to diagnose the problem further. There have been problems in the past with the contents of the certificate store of Windows. It does not look like this is the problem you are facing, but the diagnostic messages should be helpful.

@mieth can you enable the dirmngr log and give it more message, you'll be able to diagnose the problem further. There have been problems in the past with the contents of the certificate store of Windows. It does not look like this is the problem you are facing, but the diagnostic messages should be helpful.

Yes, this is in a jail. But the output above was from the same shell session inside the jail. So gpg-agent was forked from gpg which I executed in the same shell (same process) as the ls. As you can see from the output of ls, /dev/pts is mounted there. The link you provided tells to mount the devfs inside the jail. This is the case here (that's basics, it needs to be there for a lot of things to work inside a jail).

Let's try this for 2.3

Tested on a big endian machine.

$ uname -a
Linux perotto 5.15.0-2-powerpc64 #1 SMP Debian 5.15.5-2 (2021-12-18) ppc64 GNU/Linux

FYI: When you have a problem with pinentry, possible workaround is using gpg with --pinentry-mode=loopback, which redirects pinentry queries to the caller (instead of invoking pinentry session).

Thank you for the debug information.

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.