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

[David Coutadeur]

Hello Ryan,

My name is David Coutadeur and I am working for Worteks. I am also part 
of the ltb-project team (https://ltb-project.org/ 
<https://ltb-project.org/>)

I, and the LTB team, would be glad to help contributing OpenLDAP 
packages for Debian.

As you may know, ltb-project is providing many tools around LDAP, and 
especially OpenLDAP packages for Red-Hat and Debian.

We are now really close to release the 2.5 OpenLDAP packages.

There are two ways I suppose we could contribute:

   - using our LTB package in debian?

   - help making the current debian packages evolve?


Don't hesitate to contact me back if you think we can help you.

Regards,

David


 > 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!