asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder
hyc(a)symas.com wrote in ITS#8240:
> Our patch response was too hasty. There is no OpenLDAP bug here, the real
> issue is production binaries being built with asserts enabled instead of
> compiling with -DNDEBUG. That's an issue for packagers and distros to resolve.
> Closing this ITS, not an OpenLDAP bug.
Maybe I missed something. But this is the first time I've heard about -DNDEBUG
being mandatory when compiling binary packages for production use. Does it
have other effects?
And what are general rules for assert statements in OpenLDAP code?
In my own (Python) code assert statements are supposed to be only triggered if
something goes wrong *internally* (type issues etc.). If somebody manages to
trigger an assert statement with invalid input from "outside" I always
consider this to be a serious bug revealing insufficient error handling even
though e.g. web2ldap just logs the exception but won't crash. YMMV, but please
I also wonder whether there are more mandatory rules for building packages and
where I can find them.
Please don't get me wrong: My inquiry is in good faith to avoid unnecessary
ITS based on misunderstanding.
1 year, 6 months
TLS 1.3 and 0-RTT
by Michael Ströder
Are there any plans to support TLS 1.3?
The 0-RTT feature could be a significant performance gain in case LDAP
applications open a new TLS connection each time they check a password
with a bind request.
4 years, 8 months
cn=config support for non-overlay modules and naming conventions
by Quanah Gibson-Mount
The slapo-ppolicy overlay has a parameter for loading an external module
for doing additional password checks. One example of this would be the LTB
project's PPM (password policy module) extension.
However, we currently have no method in OpenLDAP for supporting
configuration for such a module via cn=config. Using this module, we can
see two basic issues:
a) There needs to be a way to load schema for the module for whatever its
configuration items are
b) There needs to be a way to use so that it can have multiple policies
(similar to ppolicy) so that you can have different password checking
policies. Something like: pwdCheckModule <modulepath> <policyDN>. In this
way, you could have multiple password policies with different password
Additionally, we currently do not have a standard on a naming convention
for manual pages, etc, for such an item. I would propose slapm-<name> (m
for module), such as "slapm-ppm.5"
Thoughts etc welcome.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
4 years, 10 months