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.

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

As this hinders the trusted-introducer setup in Keyserver centric deployments we should treat this with high priority.