openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#8687) openldap fails to link w/ openssl 1.1 built w/ no-egd
by djkurtz＠google.com 20 Sep '17

20 Sep '17

On Tue, Sep 19, 2017 at 4:43 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > --On Friday, July 07, 2017 8:45 AM +0000 djkurtz(a)google.com wrote: > >> Full_Name: Daniel Jonathan Kurtz >> Version: 2.4.45 >> OS: linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2401:fa00:1:b:dcfc:ce39:b80:8f26) > > > Out of curiosity, what OS were you compiling on that didn't have /dev/urandom available? > > --Quanah This occurs when cross compiling. See: https://github.com/openldap/openldap/blob/master/configure.in#L2197 > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > -- Daniel Kurtz | Software Engineer | djkurtz(a)google.com | 650.204.0722

1 0

Re: (ITS#8687) openldap fails to link w/ openssl 1.1 built w/ no-egd
by quanah＠symas.com 19 Sep '17

19 Sep '17

--On Friday, July 07, 2017 8:45 AM +0000 djkurtz(a)google.com wrote: > Full_Name: Daniel Jonathan Kurtz > Version: 2.4.45 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2401:fa00:1:b:dcfc:ce39:b80:8f26) Out of curiosity, what OS were you compiling on that didn't have /dev/urandom available? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8736) Add test script for cn=config replication using delta-sync
by quanah＠openldap.org 18 Sep '17

18 Sep '17

Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Currently test059 shows how replication of cn=config can work for a replica, using back-ldif and standard syncrepl, but we do not have a corresponding script using delta-syncrepl. We should similarly have a corresponding test script for cn=config MMR using delta-syncrepl for the cn=config db.

1 0

Re: (ITS#8638) Recursive mutex in libldap_r
by ondra＠mistotebe.net 18 Sep '17

18 Sep '17

> IMO using recursive mutexes means your code is broken. We introduced these for > accesslog.c but in fact we could avoid them at zero cost. Also I don't see the > relevance of libevent to this discussion. We use our own event mechanism and > it is more efficient than libevent. libevent is a dependency for the load balancer that I intend to propose for integration into the project after all the relevant dependencies have come in. There is a new version of this patch that provides an implementation on each platform or defers to the existing one (as per each platform's documentation). Untested except on POSIX and most of them seem pretty arcane anyway. ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170918-ITS8638-libldap_r-re… -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 16 Sep '17

16 Sep '17

I've been running 2.4.44 with the test patch since May and haven't seen a crash since, for what that's worth. We upgraded to 2.4.45 last week, without that patch. I'm going to see if the crash shows up again, and if it does, apply the patch to 2.4.45 and see if it goes away again. Thanks...

1 0

Re: (ITS#8731) Variadic Debug() macro
by ondra＠mistotebe.net 15 Sep '17

15 Sep '17

On Tue, Sep 12, 2017 at 12:55:20PM +0000, okuznik(a)symas.com wrote: > The patch series in the linked archive changes the logging macros to > be fully variadic: Hi Kurt, the only opposition to going ahead with a change like this I can find[0] has been based on the fact we'd be dropping support for C90 and it is your voice that puts concrete arguments forward as a reason for this. It would seem that no notable platforms remain where the host compiler would not be able to cope. With that in mind, might I suggest we decide it is time to require C99 support from 2.5 onwards? Thanks, [0] http://www.openldap.org/lists/openldap-devel/200801/msg00059.html -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8208) ppolicy supportedControl not visible in root DSE
by michael＠stroeder.com 14 Sep '17

14 Sep '17

come(a)opensides.be wrote: > I'm not sure I understand the outcome of the discussion > here, why i s 1.3.6.1.4.1.42.2.27.8.5.1 absent from the > supportedControl returned by the rootDSE? > (1.3.6.1.4.1.42.2.27.8.5.1 being > LDAP_CONTROL_PASSWORDPOLICYREQUEST) This prevents client to > know that the server supports ppolicy. Frankly I can't imagine how to make it more clear than I already did. Please re-read my follow-up here: https://www.openldap.org/its/index.cgi?findid=8208#followup2 Especially note that the original poster did *not* mention OID 1.3.6.1.4.1.42.2.27.8.5.1 to be missing. (It's present in all my OpenLDAP servers.) The original poster asked for another outdated password policy mechanism. Ciao, Michael.

1 0

Re: (ITS#8735) Significant delay setting LDAP_OPT_X_TLS_REQUIRE_CERT with invalid DNS
by michael＠stroeder.com 14 Sep '17

14 Sep '17

sean.haugh(a)vertivco.com wrote: > I'm seeing a significant delay (32s) when setting > `LDAP_OPT_X_TLS_REQUIRE_CERT` with unreachable DNS servers in > resolv.conf. We initially discovered the issue in 2.4.42 > although I've confirmed it is present in 2.4.45. AFAIK it is > not present in 2.4.23. I assume you see a delay at the client-side. Are you sure that it is not something caused by the TLS library updated in the mean-time? Which one is used by the client? You should re-test with server certs without any URLs (AIA, CRLDP extensions etc.) which might be accessed by your TLS lib. You could also monitor the DNS traffic. Some resolvers allow to switch on query logging. Or tcpdump or similar. And BTW: The most likely answer is that your resolver should always be up and running. Sometimes a local caching resolver helps to overcome upstream resolver outage. Ciao, Michael.

1 0

(ITS#8735) Significant delay setting LDAP_OPT_X_TLS_REQUIRE_CERT with invalid DNS
by sean.haugh＠vertivco.com 14 Sep '17

14 Sep '17

Full_Name: Sean Haugh Version: 2.4.45 OS: Linux URL: Submission from: (NULL) (143.166.81.254) I'm seeing a significant delay (32s) when setting `LDAP_OPT_X_TLS_REQUIRE_CERT` with unreachable DNS servers in resolv.conf. We initially discovered the issue in 2.4.42 although I've confirmed it is present in 2.4.45. AFAIK it is not present in 2.4.23.

1 0

Re: (ITS#8208) ppolicy supportedControl not visible in root DSE
by come＠opensides.be 14 Sep '17

14 Sep '17

Hello, I=E2=80=99m not sure I understand the outcome of the discussion here, why i= s 1.3.6.1.4.1.42.2.27.8.5.1 absent from the supportedControl returned by th= e rootDSE? (1.3.6.1.4.1.42.2.27.8.5.1 being LDAP_CONTROL_PASSWORDPOLICYREQUEST) This prevents client to know that the server supports ppolicy. C=C3=B4me

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