Bug#512360: RFH: openldap -- OpenLDAP server, libraries, and utilities

Ryan Tandy ryan at nardis.ca
Sat Dec 5 20:36:00 GMT 2020


I'm still looking for help with the OpenLDAP packages. I'm not an 
OpenLDAP user any more, and I would like to eventually hand off the 
package to a new maintainer.

The current 2.4 package is in OK shape. It's up-to-date in unstable and 
backports, and I'm able to handle the low volume of security updates and 
bug reports. I'm also responding to Debian-specific issues on the 
upstream support channels (lists/bugs/IRC). The status quo will probably 
be fine for bullseye; however, I'm not making much progress on 
developing or improving the package.

Here are some of the major projects that I would appreciate help with:

* Updating to OpenLDAP 2.5.

  The first 2.5 alpha has been released already. I hope the final 
  release will happen in time that we can transition to it for bookworm. 
  This will include a SONAME transition, which should be mostly painless 
  as the library API has not changed much.

  The bulk of the work will be to support slapd upgrades. The biggest 
  change is that the Berkeley DB backends (BDB and HDB) have been 
  removed. These were the default for Debian installations for a long 
  time and I know not all users have migrated to LMDB yet. We should 
  provide an automated migration from BDB/HDB to LMDB, as was done for 
  LDBM previously. There are also some old bugs in the maintainer 
  scripts for upgrading databases, which still need to be addressed.

  Upstream still supports both slapd.conf and cn=config configuration 
  (though slapd.conf is considered deprecated), so any upgrade path has 
  to support both.

* Overhauling the debian/copyright file.

  The copyright file is old and not in DEP5 format yet. We basically 
  need to do a full copyright review of the upstream source in order to 
  write a complete and correct DEP5 copyright file, and then commit to 
  maintaining it going forward.

  I don't know at all what the license of debian/* is supposed to be. We 
  might have to do some legwork of contacting previous maintainers and 
  trying to obtain copyright statements from them.

* Replacing the slapd init script with a systemd service.

  This is a smaller project, but still not as trivial as it sounds. The 
  init script supports a number of configuration variables, and it also 
  picks up some information dynamically from the slapd configuration. 
  This probably requires extracting some of the init script code to a 
  wrapper script for executing slapd with appropriate arguments.

  Supporting both slapd.conf and cn=config adds complexity here as well.

* Working with upstream on GnuTLS support.

  Upstream still supports GnuTLS, but reluctantly. They expect the 
  Debian maintainer to be actively involved with triaging and fixing 
  GnuTLS issues upstream.

  The autoca overlay is new in 2.5 and only supports OpenSSL right now. 
  Upstream are not likely to work on GnuTLS support; if we want to 
  include it in Debian, we probably have to add GnuTLS support 
  ourselves.

* Evaluating a possible switch back to OpenSSL.

  Upstream would prefer to drop the GnuTLS support, and have asked me to 
  investigate what issues on the Debian side are blocking it.

  I don't fully understand Debian's current position on OpenSSL 
  licensing and hope ftp-master will provide a more detailed statement 
  soon. This might require auditing the reverse-depends of libldap in 
  Debian and checking whether there is still GPL- or GPL2-only code 
  linking with libldap; I'm not sure.

  In any case, a switch to OpenSSL is likely to be a disruptive event 
  for all users (for example, the TLS cipher suite configuration is 
  completely incompatible) and must be approached with caution.

  If there are no blockers on the Debian side, dropping GnuTLS support 
  upstream could happen as soon as OpenLDAP 2.6.

* Working with Ubuntu to reduce their delta.

  The Ubuntu maintainers would like to reduce the delta in their 
  package. There are some changes that can be dropped during the 
  transition to 2.5 (such as the legacy GSSAPI support). There are also 
  some pieces that could be adopted in Debian (such as the apparmor and 
  ufw profiles), if we can determine the license and copyright for them.


I'm happy to provide mentoring or reviews, and to sponsor uploads, for 
anyone who would like to work on the package. If you have an interest in 
the future of OpenLDAP in Debian, please get in touch!



More information about the Pkg-openldap-devel mailing list