Quanah and Howard,
Thanks for your quick replies! I'm glad to hear there's interest in this. I
think 2.6 is a more realistic target, as I'll need to get my boss to
allocate time for this work amongst other wolfSSL tasks I've been assigned.
Look forward to a merge request in the (hopefully near) future!
On Thu, Feb 25, 2021 at 1:17 PM Quanah Gibson-Mount <quanah(a)symas.com>
> --On Thursday, February 25, 2021 12:38 PM -0600 Hayden Roche
> <haydenroche5(a)gmail.com> wrote:
> > (thanks JoBbZ). I was also pointed to this
> > issue in your issue tracking system, where a developer (Quanah
> > Gibson-Mount)
> Same person. ;)
> > Is there still interest in getting wolfSSL working with OpenLDAP's latest
> > version and integrated upstream?
> OpenLDAP 2.4 is closed to development. If you want this in for OpenLDAP
> 2.5, you'll need to get the work in ASAP, otherwise it will have to wait
> for 2.6
> Sign up for an account on our gitlab instance: https://git.openldap.org
> Fork a copy of the openldap repo.
> Create a branch for ITS9303 and do the work in that branch
> Push the branch
> Open a merge request for review
> Additionally, you'll need to add an IPR statement to ITS#9303 as
> at <https://www.openldap.org/devel/contributing.html#notice>
> A link to the MR should also be put into the ITS.
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
I'm a software engineer with wolfSSL, which is a fast, lightweight, and
FIPS-certified TLS implementation written in C. wolfSSL offers an OpenSSL
compatibility layer that presents the same API as OpenSSL, but under the
hood, calls into wolfSSL and woflCrypt (our crypto library) functions. One
of our commercial users recently had us port OpenLDAP to use wolfSSL. With
some modifications to the OpenSSL backend code (primarily in tls_o.c), I
was able to get OpenLDAP 2.4.47 building and (to my knowledge) working with
wolfSSL's OpenSSL compatibility layer. I recently reached out on your IRC
channel to see if there was any interest in supporting wolfSSL as a TLS
backend for OpenLDAP upstream and was directed to this mailing list (thanks
JoBbZ). I was also pointed to this issue in your issue tracking system,
where a developer (Quanah Gibson-Mount) expressed interest in using
Is there still interest in getting wolfSSL working with OpenLDAP's latest
version and integrated upstream? If so, I imagine we'd want to make wolfSSL
a first class citizen among the TLS backends (i.e. rather than using our
OpenSSL compatibility layer and modifying tls_o.c, use wolfSSL's native
functions and create a new tls_w.c). Looking forward to hearing from you.
As a user of slapd-ldap I've bumped into few corner cases related to handling
retries and timeouts . I think it demonstrates how non-trivial
problem proxying really is, even if it might seem quite simple for casual user
at first. While working with a patch for  I was wondering following:
My use case:
I have many proxies in the network: one per Kubernetes cluster, but large
number of clusters in the network. I'd like to reduce the number of long-
running connections to centralized server to the absolute minimum. The number
of concurrent TCP connections handled by the remote LDAP server is the
bottleneck. Optimally, all connections should be dropped as soon as client
is done with the LDAP query.
Would it be possible to disable all (or only some) caching and retry logic and
instead have the proxy mirror the behavior of the clients and remote server:
(1) Disconnect the client connection when corresponding remote connection got
(2) Disconnect the connection to the remote server when the client disconnects
from the proxy (or if remote connection is shared between many clients:
disconnect when last client disconnects)
In other words, delegate the complications back to the remote server and
clients, instead of trying to solve them at the proxy.
Could this simplify the proxy?
What would be the performance implications? In my use case the concurrent TCP
connections towards remote server would reduce, but the number of individual
connections could increase due to (2).
 Idle and connection timeout implementation
 crash if rebinding after retry fails
 retry fails after remote server disconnected
 rebind-as-user credentials lost after retrying remote connection
As usual I'm using openSUSE Build Service to build openldap2 RPMs. This
smoothly works with 2.4.x.
But building 2.5 branch snapshot fails.
Maybe OBS compiler options are set pretty strict because it outputs:
[ 147s] cc1: some warnings being treated as errors
[ 147s] make: *** [<builtin>: slapd-watcher.o] Error 1
You can look at the full build log with some warnings here: