[PATCH gnupg] dirmngr: Interrogate LDAP server when base DN specified

[Joey Berkovitz]

Thanks. I modified the proposed patch slightly - changing it to still
duplicate the user provided basedn. To avoid the mentioned memory
leak, in interrogate_ldap_dn, I check if the provided pointer is set,
and if so, free it.
I think it's preferable to use the user-provided basedn as a fallback
in case the provided LDAP DN doesn't have a PGPServerInfo, gpg would
just fallback to V1-schema operations treating the provided DN as the
keyspace DN (as GPG currently operates now).

Example LDAP schema: dc=pgp,dc=example,dc=org
  - cn=PGPServerInfo (pgpVersion = 2, pgpBaseKeySpaceDN = ou=GnuPG
Keys,dc=pgp,dc=example,dc=org)
  - ou=GnuPG Keys

Some test cases are:
  - No PGPServerInfo entry (as described above) - pushing a key
results in keys stored in the provided DN (ex: ou=GnuPG
Keys,dc=pgp,dc=example,dc=org)
  - PGPServerInfo entry, and user provided entry corresponds to
keyspace DN (ex: ou=GnuPG Keys,dc=pgp,dc=example,dc=org) - pushing a
key results in keys stored in the provided DN, but schema V2 is used
if support is indicated
  - PGPServerInfo entry, and user provided entry corresponds to
PGPServerInfo parent (ex: dc=pgp,dc=example,dc=org) - keyspace DN
auto-detected, keys pushed there, schema V2 used if supported

I tested those three cases with the attached patch. The second case
would just enable backwards compatibility, so anyone using a hardcoded
basedn would auto-upgrade to schema V2 if they have a PGPServerInfo
entry indicating support. The third case would probably represent how
future configs should be set - the provided base DN doesn't need to
correspond to the keyspace DN if the PGPServerInfo entry exists.

Best,
Joey Berkovitz

On Mon, Sep 26, 2022 at 9:54 PM NIIBE Yutaka <gniibe at fsij.org> wrote:
>
> Joey Berkovitz wrote:
> > Patch attached, related to https://dev.gnupg.org/T6047
>
> I tried to apply your patch, but I found questionable parts in your
> patch.  So, to proceed, firstly, I pushed a change of factoring to
> interrogate_ldap_dn function (993820c31521).
>
> Questionable parts for me are:
>
> * ldap_count_entries is a function name.  I don't understand "if"
>   statement evaluating ldap_count_entries.
>
> * IIUC, with user specified base DN, it may introduce a memory leak for
>   basedn.
>
> Fixing those things, I think that changes needed will be something like
> the patch attached.
>
> Could you test if it works well?
> --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dirmngr-Interrogate-LDAP-server-when-base-DN-specifi.patch
Type: application/octet-stream
Size: 2877 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220927/5001cfc4/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dirmngr-Interrogate-LDAP-server-when-base-DN-specifi.patch.sig
Type: application/octet-stream
Size: 119 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220927/5001cfc4/attachment-0003.obj>