openldap-devel

openldap-devel@openldap.org

1418 discussions

Re: New OpenLDAP TLS backend? (wolfSSL)
by Hayden Roche 20 May '21

20 May '21

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! Thanks, Hayden On Thu, Feb 25, 2021 at 1:17 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --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 > > Generally: > > 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 > documented > at <https://www.openldap.org/devel/contributing.html#notice> > > A link to the MR should also be put into the ITS. > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

ssl_cipher_list_to_bytes:no ciphers available
by Michael Ströder 06 May '21

06 May '21

HI! I have issues with OpenSSL ciphers on my openSUSE Tumbleweed and release 2.5.4 when connecting to an 2.4 provider: TLS: can't connect: error:141A90B5:SSL routines:ssl_cipher_list_to_bytes:no ciphers available. An 2.4.58 consumer replica works just fine. There is this commit in RE25 and I'm not sure whether that introduces a regression on my system: b72bce2400ce303766f355a1dd37f4012754c942 ITS#9521 Set TLSv1.3 cipher suites for OpenSSL 1.1 BTW: openSUSE has implemented something like a crypto policy configuration: https://build.opensuse.org/package/view_file/security:tls/openssl-1_1/opens… Any clue what's going on? Ciao, Michael.

2 9

slapo-ppolicy 2.4 vs. 2.5
by Michael Ströder 04 May '21

04 May '21

HI! slapo-ppolicy in OpenLDAP 2.5 shows slightly different behaviour in python-ldap0 tests (see test output below). Tests: https://gitlab.com/ae-dir/python-ldap0/-/blob/master/tests/test_ppolicy.py When working with Ondřej for solving ITS#9279 I finally "fixed" ldap0 tests to accomodate the behaviour of OpenLDAP 2.4.x. I did not feel comfortable back then because it was not clear to me whether it was the correct fix. Do you have any tests you could run against 2.4 and 2.5 to verify whether both have same behaviour? Ciao, Michael. ====================================================================== FAIL: test003_ppolicy_grace_logins (tests.test_ppolicy.TestPPolicy) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/michael/Proj/ae-dir/python-ldap0/tests/test_ppolicy.py", line 235, in test003_ppolicy_grace_logins self.assertEqual( AssertionError: 'Password expired! 1 grace logins left.' != 'Password expired! 2 grace logins left.' - Password expired! 1 grace logins left. ? ^ + Password expired! 2 grace logins left. ? ^ ====================================================================== FAIL: test001_pwdpolicy_expiration (tests.test_ppolicy.TestPwdPolicy) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/michael/Proj/ae-dir/python-ldap0/tests/test_ppolicy.py", line 285, in test001_pwdpolicy_expiration self.assertIsInstance(bind_res.ctrls[0], PasswordExpiringControl) AssertionError: <ldap0.controls.pwdpolicy.PasswordExpiredControl object at 0x7efc9d8ca760> is not an instance of <class 'ldap0.controls.pwdpolicy.PasswordExpiringControl'> ====================================================================== FAIL: test002_pwdpolicy_expired (tests.test_ppolicy.TestPwdPolicy) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/michael/Proj/ae-dir/python-ldap0/tests/test_ppolicy.py", line 306, in test002_pwdpolicy_expired l.simple_bind_s(self.user_dn, user_password.encode('utf-8')) AssertionError: INVALID_CREDENTIALS not raised

3 6

OpenLDAP 2.5 Release Candidate Testing (OpenLDAP 2.5.4)
by Quanah Gibson-Mount 22 Apr '21

22 Apr '21

This is a testing call for OpenLDAP 2.5 Release Candidate (OpenLDAP 2.5.4) Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Note that there are new features in 2.5, so please examine the options available with configure carefully. Some examples: The new load balancer, which can either be built as a module for slapd (--enable-balancer=mod) or as a standalone server (--enable-balancer=yes) The libargon2 password module (--enable-argon2). Systemd notification support (--with-systemd=yes). Thanks! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

ldap_sasl_interactive_bind_s and LDAP_SASL_QUIET
by Jordan Brown 25 Mar '21

25 Mar '21

ldap_sasl_interactive_bind_s prints SASL-related messages on stderr by default, unless you specify LDAP_SASL_QUIET. This seems wrong. The whole point of the "interact" function is to handle any required conversation with the user. In particular, in a GUI application these messages won't go to the user; more likely they will just clutter up some log. Would the OpenLDAP community be receptive to a patch that directs these messages through the "interact" function? (I think they have very little value and should just be dropped; that would be OK too.) SASL username: somename(a)EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

2 2

Some suggested 2.5 code cleanups/renames
by Hallvard Breien Furuseth 23 Mar '21

23 Mar '21

Hello. slap_op_time(time_t *t, int *nop) could previously be called with any 2 arg of those types. But now it modifies nop[1], so old code other than slap_op_time(&op->o_time, &op->o_tincr) gets a bad memory write. Source-code compat looks like a misfeature now. I'd rather rename and re-prototype: slap_op_gettime(Operation* or some new time-struct*). == Another fake array: Let's replace bi_op_bind..bi_chk_controls in BackendInfo with macros referring into a new bi_op_func[14]. Today (&bi->bi_op_bind) is used as an array here: grep -r '(&.*_bind)' And apply 'contrib/slapd-tools/wrap_slap_ops -u * | patch -p0', though that can wait a bit more - until RE24 is really surely not going to get new releases and merge conflicts with the patch. (Hm. The "delete newlines at EOF" cleanup doesn't belong there.) Related issue: slap_operation_e was the indexes to (&bi->bi_op_bind), but now it has op_txn too corresponding to bi_op_txn with a different prototype. 'grep -r op_last' shows code mentioning op_last which has not been updated to match this. Unsure what to do about this. Other than commenting the enum afterwards, anyway:-) == Any chance of wrapping struct ldapoptions' contents in some structs? Today, if a new field is added but the corresponding NULLARG is not updated to match, the later NULLARGs initialize the wrong fields and can fail. As in ITS#9332 (init ldo_tls_require_san). So anyway, one struct per LDAP_blah_NULLARG. Then replace most NULLARGs with {0}. But must add lots of macros, for the old fields. == Hallvard

2 1

Merge request management
by Ondřej Kuzník 18 Mar '21

18 Mar '21

It's a good development that we have more merge requests coming in and things are getting looked at. As things pick up, we need to be able to quickly identify which requests are waiting on review, where we're waiting on the review comments to be addressed. I guess we can keep switching the WIP: flag on the request for that one and let authors remove it when ready again. Similar when a different reviewer is needed (e.g. when I've added substantial code to an existing request) or a configure update or a backport to an older release should be done post-merge, labels might or might not be the best fit, there's also way to request review from a particular person. BTW non-project members are invited to help with review and testing, it's a great way to get familiar with the codebase and helps the project move faster and at higher quality. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

New OpenLDAP TLS backend? (wolfSSL)
by Hayden Roche 25 Feb '21

25 Feb '21

Hi everyone, 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 wolfSSL: https://bugs.openldap.org/show_bug.cgi?id=9303 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. Thanks! Hayden Roche

3 2

Question: back-ldap connection retrying and rebinding necessary?
by Tero Saarni 22 Feb '21

22 Feb '21

Hi, As a user of slapd-ldap I've bumped into few corner cases related to handling retries and timeouts [1][2][3][4]. 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 [1] 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. Question: 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 disconnected (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). Best regards, Tero [1] Idle and connection timeout implementation https://bugs.openldap.org/show_bug.cgi?id=9197 [2] crash if rebinding after retry fails https://bugs.openldap.org/show_bug.cgi?id=9288 [3] retry fails after remote server disconnected https://bugs.openldap.org/show_bug.cgi?id=9400 [4] rebind-as-user credentials lost after retrying remote connection https://bugs.openldap.org/show_bug.cgi?id=9468

2 4

some overlays missing with --enable-overlays=mod
by Michael Ströder 10 Feb '21

10 Feb '21

HI! It seems that some overlays were moved from contrib to main source. I appreciate that. autogroup lastbind smbk5pwd But it seems these are not built with --enable-overlays=mod, at least not with my .spec file: https://build.opensuse.org/package/view_file/home:stroeder:openldap25/openl… Anything I have to tweak on my side? Ciao, Michael.

2 2

← Newer
1
2
3
4
5
6
7
...
142
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel