Page MenuHome GnuPG

Dirmngr - LDAP Schema V2 not used when Base DN is specified
Closed, ResolvedPublic

Description

When publishing keys to an LDAP server with a base DN specified in the dirmngr config (https://www.gnupg.org/documentation/manuals/gnupg/Dirmngr-Options.html#:~:text=%2D%2Dkeyserver), dirmngr forces schema version 1 and as a result doesn't push newer attributes to the LDAP server.

This is problematic when using some applications such as Kleopatra, which now seem to require that key fingerprints be present in search results.

For reference, the relevant code is here: https://github.com/gpg/gnupg/blob/master/dirmngr/ks-engine-ldap.c#L559
When a base DN is specified, it bypasses the keyserver probing functionality, which would normally attempt to find the PGPServerInfo entry and flag the appropriate schema version.

It would be useful if one of the following was implemented:

  • Dirmngr could auto detect if the provided base DN is a PGPServerInfo entry and then just inspect the pgpKeySpaceDN to get the DN for the keys
  • There was a new config option to specify the DN for the PGPServerInfo entry to allow for probing with a manually specified path
  • There was a new config option to override the LDAP keyserver flags and specify that a keyserver uses schema V2

I would be happy to work on a PR for any of these options if any option is deemed acceptable.

Event Timeline

werner triaged this task as Normal priority.Jun 29 2022, 5:16 PM
werner edited projects, added Feature Request, gnupg (gpg23), dirmngr, LDAP; removed Bug Report.
werner added a subscriber: werner.

The first ideas sounds best to me. Patches please to the mailing list.

I tried to submit the below patch to gnupg-devel@lists.gnupg.org, but get an Unrouteable address error. Let me know how best to submit it

Let me know how best to submit it

Please use the address: gnupg-devel@gnupg.org
(lists.gnupg.org doesn't work now)

Any chance someone is able to review the posted patch?

Posted on the mailing list here: https://lists.gnupg.org/pipermail/gnupg-devel/2022-July/035082.html

Due to vacation the review may take some time.

just checking in about getting this patch reviewed

To proceed, I pushed an initial part as rG993820c31521: dirmngr: Factor out interrogate_ldap_dn function., which doesn't change any behavior.
Then, the point of the change will be clearer.

BTW, I have also in mind to use an AD entry to figure out the used keyserver. It turned out that people don't like to modify the schema of their AD but instead use a separate LDS.

gniibe changed the task status from Open to Testing.Oct 11 2022, 8:16 AM
werner claimed this task.