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

Turns out that the aliasing is a problem; if we allow keyserver as an alias for ldapserver in gpgsm.conf we are not able to get the value unless we add dedicated handling for this. Test in 2.3 but we will have the same problem the other way around in 2.2.

What does kleopatra use to get the list of ldap servers - gpgsm or dirmngr?

The problem comes from the way we handle an alias. That actually depends on the order the options are specified.

There are reasons why we don't used pcsc-shared by default; for example: Not all OpenPGP cards support reading the current verification state (whether a PIN has already been entered) and thus we use a local cache for this. Other shared applications may change the state behind our back or even switch to another application on the card. Thus we use the safe way.

Thanks for report. I got similar report earlier this week from gentoo user through email and made following patch for them to test. I'll push it to master soon.

Thanks

gpgme_key_t is a different kind of object than a gpgme_foo_result_t and thus has different properties.

The bug with the long filenames has been fixed but it is not yet released. Release will be in gpg4win 4.0.1 See T5754.

Hi gniibe,

Unfortunately, gdb session log and ktrace log don't have enough information to locate the cause/problem.

While trying to test the X.509 directory server configuration in Kleopatra, I stumbled over difference between 2.2 and 2.3 and a possible regression in 2.2.

thanks, looks good!

that's great news to my eyes. thanks werner!

Excuse me you are right of course. man gpgconf | grep quot says it all.

man gpg | grep quote nor man gpgconf | grep quote does not tell anything about it. I recognized the single opening quote of "string at post processing the output of gpgconf --list-options to generate a gpgconf.conf template. I just expected a closing quote for "string".

From which version on there will be global config files? The only info I found was about /etc/gnupg/gpgconf.conf and /etc/skel/.gnupg/* to manage presets.

@werner Hmm, okay. So I have tested the wrong thing. To me /etc/gnupg/gpgconf.conf looked very much like a global config file I was supposed to test. I have looked at /etc/gnupg, found the example gpgconf.conf and played around with it. It had some effects (see above), so I assumed that it should work. Since it's obvious from my tests, that it doesn't really work as documented anymore, all corresponding code should be removed entirely (or fixed if it should be kept for backward compatibility).

ikloecker: gpgconf.conf ist not anymore used since we have the global config files.

With /etc/gnupg/gpgconf.conf

[empty lines and comment lines]
*	gpgsm	verbose				[no-change]
	gpgsm	quiet				[no-change]
	gpgsm	debug-level			[no-change]
	gpgsm	log-file			[no-change]
	gpgsm	include-certs			[no-change]
	gpgsm	compliance			[no-change]
	gpgsm	default-key			[no-change]
	gpgsm	encrypt-to			[no-change]
	gpgsm	keyserver			[no-change]
	gpgsm	disable-dirmngr			[no-change]
	gpgsm	auto-issuer-key-retrieve	[no-change]
	gpgsm	p12-charset			[no-change]
	gpgsm	disable-crl-checks		[no-change]
	gpgsm	enable-crl-checks		[no-change]
	gpgsm	disable-trusted-cert-crl-check	[no-change]
	gpgsm	enable-ocsp			[no-change]
	gpgsm	disable-policy-checks		[no-change]
	gpgsm	cipher-algo			[no-change]

all options are correctly flagged as "no change" in the output of gpgconf

More weirdness. With gpgconf (GnuPG) 2.2.34-beta23 I get:

--apply-defaults is an obsolete option because we now have global config files. I would also like to get rid of --debug-level but that won't be easy. Using --debug LIST_OF_DEBUG_FLAGS is a more versatile way of specifying debug options.

Nope. The double quote indicates a string. See the man page.

Thank you, applied.

Potential fix posted here: https://invent.kde.org/pim/kleopatra/-/merge_requests/11