openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8971) slapo-accesslog hits assert
by hyc＠symas.com 02 Feb '19

02 Feb '19

michael(a)stroeder.com wrote: > Full_Name: > Version: RE24 branch > OS: openSUSE Linux > URL: > Submission from: (NULL) (212.68.198.84) > > > For the records an issue tested with Howard today: > > slapo-accesslog hits an assert checking for empty 'reqDN' after processing a > password modify extended operation. > > More information in the ITS upon request. > > Fixed in git master -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8971) slapo-accesslog hits assert
by michael＠stroeder.com 02 Feb '19

02 Feb '19

Full_Name: Version: RE24 branch OS: openSUSE Linux URL: Submission from: (NULL) (212.68.198.84) For the records an issue tested with Howard today: slapo-accesslog hits an assert checking for empty 'reqDN' after processing a password modify extended operation. More information in the ITS upon request.

1 0

Re: (ITS#8963) Start TLS failed errors on back-ldap binds / short timeout, config option request
by janne.peltonen＠helsinki.fi 01 Feb '19

01 Feb '19

On Thu, Jan 31, 2019 at 11:41:07PM +0000, Howard Chu wrote: > Thanks for the report. Note that if you simply set a "timeout" with no specific > qualifiers, it would have worked for you as well. Oh dear. Of course. And it says so cleary on the man page, too. Thank you! > At this point, the "extended" timeout was meant for the other exops that back-ldap > supports, e.g. whoami and passwordModify. Since 2.4 is feature frozen we are not > going to implement the extended timeout feature here. > > Instead, I've changed the start_tls code to use the "bind" timeout, since it will > always be used as part of a bind operation anyway. OK, thanks a lot! --Janne / Helsinki Uni

1 0

(ITS#8970) bind fails when length value is multi-byte
by lit＠cbord.com 01 Feb '19

01 Feb '19

Full_Name: Leo Tohill Version: 2.4.30 OS: Windows 10 URL: https://docs.google.com/document/d/10uKg9Nh3HLiuOzTbLfi6Z7bCfUb8x_Ai6WK5LqN… Submission from: (NULL) (74.79.8.41) Summary: openldap 2.4.30 does not accommodate multi-byte length value on bind request. First, I'll admit that I'm out of my depth here, I'm running a older version, I'm on Windows, and my package was built by I don't know. But I worked hard enough to track this down that I want you to know what I found. I might upgrade, but that's problematic. At some point my bindings from .net began failing with "the username or password is incorrect" But they were correct. I could confirm with various other tools. I captured the wire traffic to isolate the problem. It turns out that Windows forms the binding request using a multi-byte length indicator in the request. OpenLdap apparently does not accommodate this. I compared to a request generated by ldapsearch.exe. That request, which succeeds, varies only by using a single-byte length indicator. The multi-byte length value should be allowed, right? Isn't it possible to have a bind request data packet of length > 127? Which would require a multi-byte length value. Perhaps this was fixed in a later version. Screenshots of the wire capture here: https://docs.google.com/document/d/10uKg9Nh3HLiuOzTbLfi6Z7bCfUb8x_Ai6WK5LqN… Thanks for any comments.

1 0

Re: (ITS#8963) Start TLS failed errors on back-ldap binds / short timeout, config option request
by hyc＠symas.com 01 Feb '19

01 Feb '19

janne.peltonen(a)helsinki.fi wrote: > Full_Name: Janne Peltonen > Version: 2.4.44 > OS: Red Hat Enterprise Linux 7 > URL: https://www.openldap.org/lists/openldap-technical/201901/msg00038.html > Submission from: (NULL) (2001:708:110:1820:3664:a9ff:fe04:7363) > > > Proxied BINDs on back-ldap sometimes create Start TLS failed errors on the > connection from proxy to backend, and the client of the proxy receives the error > 52. We had a look at the code, and it appears that in back-ldap/bind.c, the > timeout argument of the function ldap_back_start_tls always ends up as zero, so > the timeout tv.sec and tv.usec end up being set as 0 and 100000, respectively, > by the macro LDAP_BACK_TV_SET defined in back-ldap/back-ldap.h. This means that > the actual timeout waiting for starttls operation to complete will be 0.1 > seconds, which is sometimes too little if there are latencies. We did a > quick&dirty hack to just set tv.sec to 3 and tv.usec to 0, and were no longer > able to get any Start TLS failed errors on the proxy bind. > > We did find that the back-ldap has an "extended" timeout defined in > back-ldap/config.c - except that is commented out as "not implemented". Seems to > us that if that were implemented, you could set the timeout in your ldap > database section by something like "timeout extended=" and then you could have a > longer timeout. Thanks for the report. Note that if you simply set a "timeout" with no specific qualifiers, it would have worked for you as well. At this point, the "extended" timeout was meant for the other exops that back-ldap supports, e.g. whoami and passwordModify. Since 2.4 is feature frozen we are not going to implement the extended timeout feature here. Instead, I've changed the start_tls code to use the "bind" timeout, since it will always be used as part of a bind operation anyway. > > Steps to reproduce: > 1. Configure an openldap proxy-backend pair, the proxy using the "ldap" database > and using ldap urls to connect to the backend (using ldaps urls might actually > be a workaround). Configure the binds to be proxied to the backend, too. > 2. Create a script that creates multiple - say, 200 - simultaneous connections > to the proxy, using an ldaps url to connect to the proxy, and using the same DN > to bind as. (We haven't tried to connect to the frontend using ldap+starttls, > but I would suppose that would have a similar result, since the client > establishes TLS anyway before trying to bind to the proxy.) > 3. Observe some of the binds fail (we typically get 5-6 fails for 200 > simultaneous connection), with the client of the proxy getting a "Server is > unavailable: 52" type of error, and the proxy log containing lines such as > "conn=7716 op=0 RESULT tag=97 err=52 text=Start TLS failed" after the BIND from > the client. > > Possible workaround: Configure the proxy to use ldaps urls to the backend. > > Suggested fix: Implement the "extended" timeout type in back-ldap/config.c > timeout_table, so that people can set the StartTLS timeout to a larger value > than the default 0.1 seconds. > > References: discussion thread on the OpenLDAP-Technical mailing list. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8968) Async connect mode does not work on Solaris
by quanah＠symas.com 01 Feb '19

01 Feb '19

--On Wednesday, January 30, 2019 11:19 PM +0000 vsmith(a)interlinknetworks.com wrote: > Full_Name: Vernon Smith > Version: 2.4.47 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2601:40d:4300:679a:c0c9:ced:d06f:39a4) > > > I have managed to upgrade to version 2.4.47 libldap libraries using the > Linux OS and async connect mode works fine. But when I tried to upgrade > to 2.4.47 using Solaris OS and use async connect mode, no connections > could be established to the ldap server. The libldap code did not even > send the ldap request to the ldap server. The ldap debug trace showed it > just freeing the request and returned an unable to connect. I traced the > issue to the routine ldap_int_flush_request which checks the sock_errno > return code for EAGAIN but Solaris 10 returns ENOTCONN. This error code > seems to mean the same thing as EAGAIN. I changed the code to test for > either return code and the async connect works for both Linux and Solaris > now. Here is may patch. Thanks for the report, this is now fixed in master (and will be a part of the next RE24 release). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8957)
by quanah＠symas.com 01 Feb '19

01 Feb '19

--On Wednesday, January 30, 2019 3:15 PM +0000 quanah(a)symas.com wrote: > --On Wednesday, January 30, 2019 1:44 AM -0500 Vernon Smith > <vsmith(a)interlinknetworks.com> wrote: > >> I Tried to upload it to the openldap ftp server but was not successful so >> I am trying the patch again here. Thanks for the report, this has been committed to git master (and will be part of the next RE24 release). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8959) duplicate symbols
by quanah＠symas.com 31 Jan '19

31 Jan '19

--On Thursday, January 31, 2019 9:00 AM +0000 ruga(a)protonmail.com wrote: > This is a multi-part message in MIME format. Lets try this a different way. No one is disputing you've found an issue. However, as has been noted repeatedly, there's no indication that the issue you have found is caused by the OpenLDAP software. As has been demonstrated numerous times in this thread, the software builds correctly without issue, using the flags you provided, with both gcc and clang, on multiple OSes and compiler verions. I.e., it would appear the problem surfaces with either your very specific build environment or the very specific set of compiler tools that you've installed. As you've noted, your particular environment is able to compile other software without hitting this issue. That's great. That however does not mean that the issue you're encountering is a bug with the OpenLDAP software. The fact that other compiler chain combinations do not hit this problem would appear to back this up. At this point, the onus is on you to clearly and unequivocally demonstrate the issue is specific to OpenLDAP as the issue more appears to be on the toolchain side. And that happens as well. I once hit a problem that was due to a bug in GCC's optimization strategies with values > -O2 (I.e., -O3, -O4, etc). It only occurred with one particular piece of software I was compiling out of several hundred software packages. And only with that particular version of GCC. But it was also clearly *not* the fault of the software. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8575) Argon2 Password hashing contrib module
by simon＠slevermann.de 31 Jan '19

31 Jan '19

Hi, I have essentially given up on doing this, because I no longer work for the employer that had me work on this, and at the time I did, I never got the thing done. The code itself worked when I tried it, but it has the caveat of not being configurable. I never quite found out how to properly implement configuration of a module that isn't an overlay, so I never got that done. Feel free to adjust the existing code, it should be adaptable to libsodium relatively easily. Cheers, Simon Am 31.01.2019 um 16:17 schrieb Raphael Geissert: > Hi, > > Is there any progress on a libsodium-based module? Or is there any > chance that the current version be integrated as-is ("one is better > than none")? > > Regards,

1 0

Re: (ITS#8575) Argon2 Password hashing contrib module
by atomo64＠gmail.com 31 Jan '19

31 Jan '19

Hi, Is there any progress on a libsodium-based module? Or is there any chance that the current version be integrated as-is ("one is better than none")? Regards, -- Raphael Geissert

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs