Page MenuHome GnuPG

gpgconf: Ignores keyserver option in gpgsm.conf
Closed, ResolvedPublic

Description

Copied from T5732#153999, so that the issue can be handled separately:

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

${GNUPGHOME}/gpgsm.conf:

keyserver ldaps://keyserver.example.com

GnuPG 2.3:

$ gpgconf --version
gpgconf (GnuPG) 2.3.5-beta17
[...]
$ gpgconf --list-options gpgsm | grep server:
keyserver:4:0::33:1::::"ldaps%3a//keyserver.example.com

GnuPG 2.2:

$ gpgconf --version
gpgconf (GnuPG) 2.2.34-beta23
[...]
$ gpgconf --list-options gpgsm | grep server:
Note: no default option file '/etc/gnupg/gpgsm.conf'
reading options from '/home/ingo/dev/g10/.gnupghomes/2.2/gpgsm.conf'
keyserver:4:0::33:1::::

I found out that in 2.3 find_option() is called with "keyserver" in retrieve_options_from_program while in 2.2 find_option() is called with "ldapserver" (which seems to be defined as alias for gpgsm's keyserver option). Apparently, the option parsing differs between 2.2 and 2.3 and in 2.2 it seems to be broken (at least for the keyserver option).

Event Timeline

ikloecker created this object with edit policy "Contributor (Project)".

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

But there is another problem: keyserver and ldapserver should not anymore be used in gpg/gpgsm. Instead ldapserver and keyserver should be set in dirmngr.conf. Thus I wonder why we still have them in gpgconf defined for gpg and gpgsm. Sure, they can be used to override the values given in dirmngr.conf but is it really useful to announce them via gpgconf?

For OpenPGP we set keyserver in gpg.conf to invisible and in dirmngr.conf to basic. All good. The invisible keyserver can be used to test for a value set in gpg.conf.

For S/MIME

  • in 2.3 we set ldapserver in gpgsm.conf to basic and don't have ldapserver in dirmngr.conf
  • in 2.2 we set keyserver in gpgsm.conf to basic and don't have ldapserver in dirmngr.conf

Shouldn't we also set this to invisible and enable ldapserver in dirmngr.conf for use by gpgconf?

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

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.

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.

In any case, I will add support for the new dirmngr/ldapserver to Kleopatra: T5801: Kleopatra: Add support for the new dirmngr/ldapserver option to configure X.509 servers.

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.

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

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

$ gpgconf --list-options gpgsm | grep "^ldapserver"
ldapserver:4:3::33:1::::

with

$ cat gpgsm.conf
keyserver ldap.gpgsm.example.com::::o=DFN-Verein,c=DE:starttls
keyserver ldap:ldap.gpgsm.example.com::::o=DFN-Verein,c=DE:ldaptls

This proves my point that the ldapserver alias of gpgsm's keyserver option is causing nothing but trouble.

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.

ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 24 2023, 2:12 PM