This still seems to be a problem:

You can close this ticket. It's a jail-specific behavior when the jail is entered from the host via command line (https://lists.freebsd.org/archives/freebsd-hackers/2022-February/000832.html for the curious people) and something is used which closes all FDs. When the jail is accessed via ssh, it works.

user@debian:~$ gpg --debug-all --keyserver hkp://keyserver.ubuntu.com --recv-key
s DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: reading options from '/home/user/.gnupg/gpg.conf'
gpg: reading options from '[cmdline]'
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/user/.gnupg
gpg: DBG: chan_3 <- # Config: /home/user/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.2.27 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.2.27
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkp://keyserver.ubuntu.com
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_GET -- 0xDF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: DBG: chan_3 <- ERR 219 Server indicated a failure <Unspecified source>
gpg: keyserver receive failed: Server indicated a failure
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0

outmix=0 getlvl1=0/0 getlvl2=0/0

gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/65536 bytes in 0 blocks

Actually is was/is a chain of bugs due to changing some URLs in confirmation mails from http to https.

GpgOL 2.5.2 has been released

I think this will break the build if kleopatrarc does not exist (because of the set -e). This may be intended, but in the commit log you wrote "[...] if it exists". I would have expected a test -f.

It was addressed in rC04f325d8917d: released 1.1.4 as "(obsolete)" feature, in Aug 2001.

In T5816#154715, @ikloecker wrote:

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

Recently, the gnupg.org mailing list manager started to prepend the lists. subdomain to the List-Id (which caused my email filters to fail) and to everything else. Probably due to an accidentally changed configuration.

Instead, let us remove the feature.

Optional automatic retrieval after import of new OpenPGP keys is now also possible.

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.