Since you are using C++, I suggest that you have a look at GpgSetOwnerTrustEditInteractor in the C++ bindings of gpgme. Have a look at QGpgMEChangeOwnerTrustJob in the Qt bindings of gpgme to see how it's used even if you do not want to use Qt.

Hi,
(Exec format error), read 0 bytes

While searching for a solution to this, I found multiple reports of people that appear to be impacted by this 5 year old issue.

Did you make another request for locating keys via WKD after adding the debug flags? I'm asking because when I do this I get the following log:

2022-02-10 17:49:59 dirmngr[6780] listening on socket '/run/user/1000/gnupg/d.f3hdqcrmjwf98p87yqjmuctx/S.dirmngr'
2022-02-10 17:49:59 dirmngr[6781.0] permanently loaded certificates: 130
2022-02-10 17:49:59 dirmngr[6781.0]     runtime cached certificates: 0
2022-02-10 17:49:59 dirmngr[6781.0]            trusted certificates: 130 (130,0,0,0)
2022-02-10 17:49:59 dirmngr[6781.0] failed to open cache dir file '/tmp/tmp.8P2EakNghu/crls.d/DIR.txt': No such file or directory
2022-02-10 17:49:59 dirmngr[6781.0] creating directory '/tmp/tmp.8P2EakNghu/crls.d'
2022-02-10 17:49:59 dirmngr[6781.0] new cache dir file '/tmp/tmp.8P2EakNghu/crls.d/DIR.txt' created
2022-02-10 17:49:59 dirmngr[6781.6] handler for fd 6 started
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> # Home: /tmp/tmp.8P2EakNghu
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> # Config: /tmp/tmp.8P2EakNghu/dirmngr.conf
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> OK Dirmngr 2.3.5-beta17 at your service
2022-02-10 17:49:59 dirmngr[6781.6] connection from process 6779 (1000:100)
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 <- GETINFO version
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> D 2.3.5-beta17
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> OK
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 <- WKD_GET -- werner.koch@gnupg.com
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: libdns initialized
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: resolve_dns_name(openpgpkey.gnupg.com): No name
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: getsrv(_openpgpkey._tcp.gnupg.com) -> 0 records
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> S SOURCE https://gnupg.com
2022-02-10 17:49:59 dirmngr[6781.6] number of system provided CAs: 390
2022-02-10 17:49:59 dirmngr[6781.6] DBG: Using TLS library: GNUTLS 3.7.3
2022-02-10 17:49:59 dirmngr[6781.6] DBG: http.c:connect_server: trying name='gnupg.com' port=443
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: resolve_dns_name(gnupg.com): Success
2022-02-10 17:49:59 dirmngr[6781.6] DBG: http.c:1917:socket_new: object 0x00007f524c290e20 for fd 7 created
2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:request:
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> GET /.well-known/openpgpkey/hu/waoubdep9643akkesx4xm3ynstfffiok?l=werner.koch HTTP/1.0\r\n
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> Host: gnupg.com\r\n
2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:request-header:
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> \r\n
2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:response:
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> HTTP/1.0 200 OK\r\n
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Date: Thu, 10 Feb 2022 16:49:59 GMT'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Server: Boa/0.94.14rc21'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Accept-Ranges: bytes'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Connection: close'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Content-Length: 957'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Last-Modified: Mon, 28 Jun 2021 17:47:11 GMT'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Content-Type: text/plain'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: ''
2022-02-10 17:50:00 dirmngr[6781.6] DBG: (957 bytes sent via D lines not shown)
2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 -> OK
2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 <- BYE
2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 -> OK closing connection
2022-02-10 17:50:00 dirmngr[6781.6] handler for fd 6 terminated

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.

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.

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

@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.

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

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.

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.

disk full. Fixed. Thanks.

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).

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.

@gniibe Thanks a bunch for the quick fix!

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.

Here is the output of --list-packets of the offending key, anonymised:

1. off=0 ctb=99 tag=6 hlen=3 plen=418 :public key packet: version 4, algo 17, created 985690138, expires 0 pkey[0]: [1024 bits] pkey[1]: [160 bits] pkey[2]: [1024 bits] pkey[3]: [1023 bits] keyid: <KEY_ID>
2. off=421 ctb=b4 tag=13 hlen=2 plen=35 :user ID packet: "XXXXXXXXXXXXX"
3. off=458 ctb=88 tag=2 hlen=2 plen=120 :signature packet: algo 17, keyid <KEY_ID> version 4, created 1629537425, md5len 0, sigclass 0x13 digest algo 2, begin of digest a8 22 hashed subpkt 33 len 21 (issuer fpr v4 <XXXXXXXXXXXXXX><KEY_ID>) hashed subpkt 2 len 4 (sig created 2021-08-21) hashed subpkt 27 len 1 (key flags: 23) hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2) hashed subpkt 21 len 5 (pref-hash-algos: 8 9 10 11 2) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID <KEY_ID>) data: [158 bits] data: [159 bits]
4. off=580 ctb=b9 tag=14 hlen=3 plen=525 :public sub key packet: version 4, algo 16, created 985690139, expires 0 pkey[0]: [2048 bits] pkey[1]: [2 bits] pkey[2]: [2046 bits] keyid: YYYYYYYYYYYYYYY
5. off=1108 ctb=88 tag=2 hlen=2 plen=63 :signature packet: algo 17, keyid <KEY_ID> version 3, created 985690139, md5len 5, sigclass 0x18 digest algo 2, begin of digest 94 e5 data: [159 bits] data: [156 bits]

This code

Thanks, Werner. This was originally reported by Alejandro Masino.

Pushed the change in rE433aba9e778e: build,tests: Fix detection of have_lock_optimization..

@marv Thank you for your report.

Hey gniibe,

Thanks

Thanks for the report. To keep things easy the empty comment is now translated to "(none)".

I added --ldapserver to gpgsm because of confusion of what a keyserver is. Right now we see a problem only with this alias but it is a more general problem with aliases. My patch to master was a for public testing - let's discuss this on the phone.

The above change now also makes gpgconf from master ignore the keyserver option in gpgsm.conf.

$ gpgconf --version
gpgconf (GnuPG) 2.3.5-beta17

For what it's worth: I suggest to remove the ldapserver alias of gpgsm's keyserver option in GnuPG 2.2 and 2.3 again. It was added not too long ago (in June 2021) and it was added after the new dirmngr/ldapserver option was added. The alias is causing regressions and trouble with its only benefit (as far as I can see) being that dirmngr has an option of the same name for the same purpose.

For X.509 servers Kleopatra currently looks at gpgsm/keyserver with a fallback to dirmngr/LDAP Server. The gpgconf interface change

* tools/gpgconf-comp.c (known_options_gpgsm): Rename "keyserver" to
"ldapserver" and set level to invisible.

in rG0b4fdbd5f41e: gpgconf: Return --ldapserver and --keyserver from dirmngr. breaks configuration of X.509 servers with existing versions of Kleopatra. I suggest to revert this change to unbreak Kleopatra.

Thanks for report. Those powerpc vector implementations expect that compiler optimizations are enabled and here provided CFLAGS did not have '-Ox' parameter. This could be worked around by introducing -O2 always when building those files (confiugre.ac & cipher/Makefile.am change) or using 'optimize' attributes to required functions (cipher/*-ppc*.c change).