- openldap-bugs - openldap.org

(ITS#7879) liblmdb "mtest" programs do not build on mingw64
by batterseapower＠hotmail.com 22 Jun '14

22 Jun '14

Full_Name: Max Bolingbroke Version: LMDB HEAD OS: Windows URL: ftp://ftp.openldap.org/incoming/max-bolingbroke-20140622.patch Submission from: (NULL) (81.111.197.81) srandom/random do not appear to be defined on mingw. The trivial patch in max-bolingbroke-20140622.patch simply defines these functions to the C standard equivalents on Windows, which lets LMDB build cleanly there. I, Maximilian Bolingbroke, hereby place the following modifications to liblmdb (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7877) please make gcrypt optional with newer gnutls
by ryan＠nardis.ca 21 Jun '14

21 Jun '14

This is a multi-part message in MIME format. --------------010505020103090906040401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit This might be a better patch, if the build system change is acceptable. --------------010505020103090906040401 Content-Type: text/x-patch; name="0001-ITS-7877-detect-whether-gnutls-uses-gcrypt.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-ITS-7877-detect-whether-gnutls-uses-gcrypt.patch" >From e904900beb419576abc098e96deda04e53119603 Mon Sep 17 00:00:00 2001 From: Ryan Tandy <ryan(a)nardis.ca> Date: Fri, 20 Jun 2014 14:44:23 -0700 Subject: [PATCH] ITS#7877 detect whether gnutls uses gcrypt --- configure.in | 14 ++++++++++++++ libraries/libldap/tls_g.c | 20 ++++++++++++++++++-- 2 files changed, 32 insertions(+), 2 deletions(-) diff --git a/configure.in b/configure.in index 84bfc8a..27fe13a 100644 --- a/configure.in +++ b/configure.in @@ -1223,6 +1223,20 @@ if test $ol_link_tls = no ; then fi fi +if test $ol_with_tls = gnutls ; then + AC_CHECK_HEADERS(gcrypt.h) + + if test $ac_cv_header_gcrypt_h = yes ; then + AC_CHECK_LIB(gnutls, gcry_cipher_open, + [have_gnutls_gcrypt=yes], [have_gnutls_gcrypt=no]) + + if test $have_gnutls_gcrypt = yes ; then + AC_DEFINE(HAVE_GNUTLS_GCRYPT, 1, + [define if GnuTLS is using GCrypt]) + fi + fi +fi + dnl NOTE: caller must specify -I/path/to/nspr4 and -I/path/to/nss3 dnl and -L/path/to/nspr4 libs and -L/path/to/nss3 libs if those libs dnl are not in the default system location diff --git a/libraries/libldap/tls_g.c b/libraries/libldap/tls_g.c index ee83b5c..417c768 100644 --- a/libraries/libldap/tls_g.c +++ b/libraries/libldap/tls_g.c @@ -43,10 +43,16 @@ #include <gnutls/gnutls.h> #include <gnutls/x509.h> -#include <gcrypt.h> #if LIBGNUTLS_VERSION_NUMBER >= 0x020200 #define HAVE_CIPHERSUITES 1 +#else +#undef HAVE_CIPHERSUITES +#endif + +#ifdef HAVE_GNUTLS_GCRYPT +#include <gcrypt.h> +#if LIBGNUTLS_VERSION_NUMBER >= 0x020200 /* This is a kludge. gcrypt 1.4.x has support. Recent GnuTLS requires gcrypt 1.4.x * but that dependency isn't reflected in their configure script, resulting in * build errors on older gcrypt. So, if they have a working build environment, @@ -54,9 +60,9 @@ */ #define HAVE_GCRYPT_RAND 1 #else -#undef HAVE_CIPHERSUITES #undef HAVE_GCRYPT_RAND #endif +#endif #ifndef HAVE_CIPHERSUITES /* Versions prior to 2.2.0 didn't handle cipher suites, so we had to @@ -143,6 +149,15 @@ tlsg_mutex_unlock( void **lock ) return ldap_pvt_thread_mutex_unlock( *lock ); } +#if GNUTLS_VERSION_NUMBER >= 0x020b00 +tlsg_thr_init( void ) +{ + gnutls_global_set_mutex (tlsg_mutex_init, + tlsg_mutex_destroy, + tlsg_mutex_lock, + tlsg_mutex_unlock); +} +#else static struct gcry_thread_cbs tlsg_thread_cbs = { GCRY_THREAD_OPTION_USER, NULL, @@ -158,6 +173,7 @@ tlsg_thr_init( void ) { gcry_control (GCRYCTL_SET_THREAD_CBS, &tlsg_thread_cbs); } +#endif #endif /* LDAP_R_COMPILE */ /* -- 1.9.1 --------------010505020103090906040401--

1 0

(ITS#7878) OpenLDAP MinGW Build Problem
by ron＠zytrax.com 20 Jun '14

20 Jun '14

Full_Name: Ron Aitchison Version: 2.4.39 OS: Windows 7/MinGW-w64/MSYS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.230.141.32) Checked the build error reports before submitting Building OpenLDAP 2.4.39 under MinGW-w64 (Win32 chain) and MSYS Configure command ./configure --prefix=/target LIBS='-lpcre -lgdi32 -lpthread' --enable-overlays --disable-shared CPPFLAGS='-I/target/include' LDFLAGS='-L/target/lib' make depend - works make - fails with undefined uint32_t in /servers/slapd/back-mdm/init.c Since this works on standard systems it is clearly some artifact of MinGW and/or configure arguments. Fixed by adding #include <stdint.h> in /servers/slapd/back-mdm/back-mdm.h. Make then ran to completion and slapd loaded. Since stdint.h is 'double include' safe there is probably no down-side to this quick fix.

1 0

(ITS#7877) please make gcrypt optional with newer gnutls
by ryan＠nardis.ca 20 Jun '14

20 Jun '14

Full_Name: Ryan Tandy Version: HEAD OS: Debian unstable URL: Submission from: (NULL) (142.32.208.235) Debian bug report: https://bugs.debian.org/745231 Quoting Andreas Metzler: "given that gmp has been dual-licensed LGPLv3+/GPLv2+ it should be possible to switch openldap over to the newer version of gnutls. Upstream's 0205e83f4670d10ad3c6ae4b8fc5ec1d0c7020c0 lets the Debian package build successfully (including testsuite). However even with patch there is still some work to be done. libraries/libldap/tls_g.c has some gcrypt related code that should be simply unnecessary with gnutls3, therefore it should not link against libgcrypt either. (Except for contrib/slapd-modules/smbk5pwd/smbk5pwd.c)." The following changes make gcrypt optional for libldap. For versions where both nettle and gcrypt are supported, I assume the default since no mechanism is provided for detecting which is actually in use. Tested with GnuTLS 2.8.6 and 3.2.15. --- a/libraries/libldap/tls_g.c +++ b/libraries/libldap/tls_g.c @@ -43,10 +43,17 @@ #include <gnutls/gnutls.h> #include <gnutls/x509.h> -#include <gcrypt.h> #if LIBGNUTLS_VERSION_NUMBER >= 0x020200 #define HAVE_CIPHERSUITES 1 +#else +#undef HAVE_CIPHERSUITES +#endif + +/* gnutls >= 2.11.1 no longer uses gcrypt by default */ +#if LIBGNUTLS_VERSION_NUMBER < 0x020b01 +#include <gcrypt.h> +#if LIBGNUTLS_VERSION_NUMBER >= 0x020200 /* This is a kludge. gcrypt 1.4.x has support. Recent GnuTLS requires gcrypt 1.4.x * but that dependency isn't reflected in their configure script, resulting in * build errors on older gcrypt. So, if they have a working build environment, @@ -54,9 +61,10 @@ */ #define HAVE_GCRYPT_RAND 1 #else -#undef HAVE_CIPHERSUITES #undef HAVE_GCRYPT_RAND #endif +#endif + #ifndef HAVE_CIPHERSUITES /* Versions prior to 2.2.0 didn't handle cipher suites, so we had to @@ -143,6 +151,7 @@ tlsg_mutex_unlock( void **lock ) return ldap_pvt_thread_mutex_unlock( *lock ); } +#if GNUTLS_VERSION_NUMBER <= 0x020b00 static struct gcry_thread_cbs tlsg_thread_cbs = { GCRY_THREAD_OPTION_USER, NULL, @@ -158,6 +167,16 @@ tlsg_thr_init( void ) { gcry_control (GCRYCTL_SET_THREAD_CBS, &tlsg_thread_cbs); } +#else +static void +tlsg_thr_init( void ) +{ + gnutls_global_set_mutex (tlsg_mutex_init, + tlsg_mutex_destroy, + tlsg_mutex_lock, + tlsg_mutex_unlock); +} +#endif #endif /* LDAP_R_COMPILE */ /* I have not looked at smbk5pwd yet.

1 0

Re: (ITS#5184) pkg-config file for libraries
by bj＠sernet.de 17 Jun '14

17 Jun '14

On 2014-06-17 at 12:36 -0700 Howard Chu sent off: > If you're depending on some unknown OpenLDAP install to provide all > of the features that your Samba package needs, you need more than > luck. You need to know that it was built against a compatible > Kerberos library, a sane Cyrus SASL version, and a working crypto > library. The only way to know that is to build it yourself against > valid packages, in which case, you don't need to go grubbing through > the system looking for them. many people are happy with their own installation of openldap or whatever package. Also I know what we have to check for to have a sufficient ldap implementation for our Samba builds, believe me :-) > If you're depending on some OpenLDAP that was packaged by someone > else, then you should be asking them to provide a pkg-config file > for their package. Installation issues are strictly not our concern, > we distribute source code. That should have already been clear from > http://www.openldap.org/its/index.cgi/Archive.Build?id=5184 Followup okay, I didn't explicitly write that I disagree. I disgree on that statement by the way :-) usually package maintainers don't write .pc files they install the .pc files that the source code ships. We also ship .pc files for all of our libraries we ship in Samba. "make install" puts in the right content. > 1. > > Even if we provided a .pc file, you still have to guess where *that* > got installed - was it in /usr, or in /usr/local, or somewhere else? to get the location of the pkg-config file is really the smallest pain. > I've certainly never seen pkg-config as a standard component of AIX > or Solaris. What difference does it make here if pkg-config is a *standard* component or if it has to be separately installed? > > Is pkg-config even supported on AIX? it is, google "pkg-config aix" shows you. To have a pkg-config files is something openldap *benefits* from because it ensures that people can build agains openldap without big trouble. I'm not sure if you really see how much benefit openldap gets out of those trivial to generate .pc files actually. If people are able to build against mozldap because just because there is a simple .pc file which sets the compile and link flags right, then mozldap might become their prefered library in the future. It's up to you if you want to make it easy or hard for people to use your software. Cheers Björn

1 0

Re: (ITS#5184) pkg-config file for libraries
by hyc＠symas.com 17 Jun '14

17 Jun '14

Björn JACKE wrote: > On 2014-06-17 at 07:04 -0700 Howard Chu sent off: >> bj(a)sernet.de wrote: >>> for Samba we really have some pain to get the right compile and linker flags >>> for different architectures, especially there, where OpenLDAP is not a >>> first-class citizen like on AIX. >>> >>> mozldap offers pkg-config files which we will start to use in Samba soon. It >>> would be great if OpenLDAP would offer a pkg-config file also to not have to >>> make wild guesses which linker/compile flags and which paths to use. >> >> I don't see the problem. There are no special compiler or linker >> flags for applications to use libldap. > > if you build on a system where you don't know what LDAP library you have you > exactly have to test for the existing header files, you have to test for the > libs that you find in the library search paths (and maybe also in > library paths that are not in the search path), you have to look for > existing symbols to know which exact flavor of the lib you have, you > have to use the right include paths. All those things that you have to > look up, have to fit together also. If you are LUCKY they will fit together on > an AIX or on a Solaris box. If not, you use the right header files but the > wrong linker flags, there are many things to screw up. It is a huge bunch of > work to get all this information pieces together and puzzle them right for your > build system. In Samba we had have a hard time to do that in the past and with > the new waf base build system we have to fix a lot that was working before. The > LDAP libaries (also OpenLDAP on Unix systems...) have always been a major pain > for the build system and a pkg-config file, which we can just use to get the > right compiler and linker flags would be a great help for that and it > would make the build agains openldap much more predictable and stable. > If you're depending on some unknown OpenLDAP install to provide all of the features that your Samba package needs, you need more than luck. You need to know that it was built against a compatible Kerberos library, a sane Cyrus SASL version, and a working crypto library. The only way to know that is to build it yourself against valid packages, in which case, you don't need to go grubbing through the system looking for them. If you're depending on some OpenLDAP that was packaged by someone else, then you should be asking them to provide a pkg-config file for their package. Installation issues are strictly not our concern, we distribute source code. That should have already been clear from http://www.openldap.org/its/index.cgi/Archive.Build?id=5184 Followup 1. Even if we provided a .pc file, you still have to guess where *that* got installed - was it in /usr, or in /usr/local, or somewhere else? I've certainly never seen pkg-config as a standard component of AIX or Solaris. Is pkg-config even supported on AIX? -- -- 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#5184) pkg-config file for libraries
by bj＠sernet.de 17 Jun '14

17 Jun '14

On 2014-06-17 at 07:04 -0700 Howard Chu sent off: > bj(a)sernet.de wrote: > >for Samba we really have some pain to get the right compile and linker flags > >for different architectures, especially there, where OpenLDAP is not a > >first-class citizen like on AIX. > > > >mozldap offers pkg-config files which we will start to use in Samba soon. It > >would be great if OpenLDAP would offer a pkg-config file also to not have to > >make wild guesses which linker/compile flags and which paths to use. > > I don't see the problem. There are no special compiler or linker > flags for applications to use libldap. if you build on a system where you don't know what LDAP library you have you exactly have to test for the existing header files, you have to test for the libs that you find in the library search paths (and maybe also in library paths that are not in the search path), you have to look for existing symbols to know which exact flavor of the lib you have, you have to use the right include paths. All those things that you have to look up, have to fit together also. If you are LUCKY they will fit together on an AIX or on a Solaris box. If not, you use the right header files but the wrong linker flags, there are many things to screw up. It is a huge bunch of work to get all this information pieces together and puzzle them right for your build system. In Samba we had have a hard time to do that in the past and with the new waf base build system we have to fix a lot that was working before. The LDAP libaries (also OpenLDAP on Unix systems...) have always been a major pain for the build system and a pkg-config file, which we can just use to get the right compiler and linker flags would be a great help for that and it would make the build agains openldap much more predictable and stable.

1 0

Re: (ITS#5184) pkg-config file for libraries
by hyc＠symas.com 17 Jun '14

17 Jun '14

bj(a)sernet.de wrote: > for Samba we really have some pain to get the right compile and linker flags > for different architectures, especially there, where OpenLDAP is not a > first-class citizen like on AIX. > > mozldap offers pkg-config files which we will start to use in Samba soon. It > would be great if OpenLDAP would offer a pkg-config file also to not have to > make wild guesses which linker/compile flags and which paths to use. I don't see the problem. There are no special compiler or linker flags for applications to use libldap. -- -- 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#5184) pkg-config file for libraries
by bj＠sernet.de 17 Jun '14

17 Jun '14

for Samba we really have some pain to get the right compile and linker flags for different architectures, especially there, where OpenLDAP is not a first-class citizen like on AIX. mozldap offers pkg-config files which we will start to use in Samba soon. It would be great if OpenLDAP would offer a pkg-config file also to not have to make wild guesses which linker/compile flags and which paths to use.

1 0

Re: (ITS#7765) Crash when adding syncrepl configuration in cn=config without search base
by clem.oudot＠gmail.com 16 Jun '14

16 Jun '14

--001a11c3c678534ebd04fbf0f3b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2014-05-23 16:09 GMT+02:00 <hyc(a)symas.com>: > coudot(a)linagora.com wrote: > > Full_Name: Cl=C3=A9ment OUDOT > > Version: 2.4.38 > > OS: GNU/Linux > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (88.173.78.196) > > > > > > When adding an olcSyncrepl attribute in my cn=3Dconfig, OpenLDAP crashe= d. > > > > The syslog output is: > > > > Dec 16 11:56:42 ader slapd[8707]: conn=3D1096 op=3D0 BIND dn=3D"cn=3Dco= nfig" > method=3D128 > > Dec 16 11:56:42 ader slapd[8707]: conn=3D1096 op=3D0 BIND dn=3D"cn=3Dco= nfig" > mech=3DSIMPLE > > ssf=3D0 > > Dec 16 11:56:42 ader slapd[8707]: conn=3D1096 op=3D0 RESULT tag=3D97 er= r=3D0 > text=3D > > Dec 16 11:56:42 ader slapd[8707]: conn=3D1096 op=3D1 MOD > > dn=3D"olcDatabase=3D{2}mdb,cn=3Dconfig" > > Dec 16 11:56:42 ader slapd[8707]: conn=3D1096 op=3D1 MOD attr=3Dolcacce= ss > olcdbindex > > olcsyncrepl > > Dec 16 11:56:42 ader slapd[8707]: olcSyncrepl: value #0: Error: Malform= ed > > "syncrepl" line in slapd config file, missing searchbase. > > Dec 16 11:56:42 ader slapd[8707]: failed to add syncinfo > > Dec 16 11:56:42 ader slapd[8707]: ch_calloc of 1 elems of 0 bytes faile= d > > > > > > I have no gdb trace to give for now, if you think it is required, I wil= l > try to > > find time to do it. But it should be easy to reproduce the issue on you= r > side. > > Please provide your exact ldapmodify request and the database config befo= re > the modify attempt, thanks. > Hi, I tried to reproduce with 2.4.39, without success: 539ebd5e conn=3D1000 fd=3D12 ACCEPT from IP=3D127.0.0.1:56063 (IP=3D0.0.0.0= :5389) 539ebd5e conn=3D1000 op=3D0 BIND dn=3D"cn=3Dconfig" method=3D128 539ebd5e conn=3D1000 op=3D0 BIND dn=3D"cn=3Dconfig" mech=3DSIMPLE ssf=3D0 539ebd5e conn=3D1000 op=3D0 RESULT tag=3D97 err=3D0 text=3D 539ebd5e conn=3D1000 op=3D1 MOD dn=3D"olcDatabase=3D{2}mdb,cn=3Dconfig" 539ebd5e conn=3D1000 op=3D1 MOD attr=3DolcSyncrepl 539ebd5e olcSyncrepl: value #0: Error: Malformed "syncrepl" line in slapd config file, missing searchbase. 539ebd5e failed to add syncinfo 539ebd5e conn=3D1000 op=3D1 RESULT tag=3D103 err=3D80 text=3DError: Malform= ed "syncrepl" line in slapd config file, missing searchbase 539ebd5e conn=3D1000 op=3D2 UNBIND 539ebd5e conn=3D1000 fd=3D12 closed So it seems there is no more issue with the latest OpenLDAP version. Cl=C3=A9ment. --001a11c3c678534ebd04fbf0f3b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail= _quote">2014-05-23 16:09 GMT+02:00 <span dir=3D"ltr"><<a href=3D"mailto= :hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>></span>:<br><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= solid rgb(204,204,204);padding-left:1ex"> <a href=3D"mailto:coudot@linagora.com">coudot(a)linagora.com</a> wrote:<br> > Full_Name: Cl=C3=A9ment OUDOT<br> > Version: 2.4.38<br> > OS: GNU/Linux<br> > URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ft= p://ftp.openldap.org/incoming/</a><br> > Submission from: (NULL) (88.173.78.196)<br> ><br> ><br> > When adding an olcSyncrepl attribute in my cn=3Dconfig, OpenLDAP crash= ed.<br> ><br> > The syslog output is:<br> ><br> > Dec 16 11:56:42 ader slapd[8707]: conn=3D1096 op=3D0 BIND dn=3D"c= n=3Dconfig" method=3D128<br> > Dec 16 11:56:42 ader slapd[8707]: conn=3D1096 op=3D0 BIND dn=3D"c= n=3Dconfig" mech=3DSIMPLE<br> > ssf=3D0<br> > Dec 16 11:56:42 ader slapd[8707]: conn=3D1096 op=3D0 RESULT tag=3D97 e= rr=3D0 text=3D<br> > Dec 16 11:56:42 ader slapd[8707]: conn=3D1096 op=3D1 MOD<br> > dn=3D"olcDatabase=3D{2}mdb,cn=3Dconfig"<br> > Dec 16 11:56:42 ader slapd[8707]: conn=3D1096 op=3D1 MOD attr=3Dolcacc= ess olcdbindex<br> > olcsyncrepl<br> > Dec 16 11:56:42 ader slapd[8707]: olcSyncrepl: value #0: Error: Malfor= med<br> > "syncrepl" line in slapd config file, missing searchbase.<br= > > Dec 16 11:56:42 ader slapd[8707]: failed to add syncinfo<br> > Dec 16 11:56:42 ader slapd[8707]: ch_calloc of 1 elems of 0 bytes fail= ed<br> ><br> ><br> > I have no gdb trace to give for now, if you think it is required, I wi= ll try to<br> > find time to do it. But it should be easy to reproduce the issue on yo= ur side.<br> <br> Please provide your exact ldapmodify request and the database config before= <br> the modify attempt, thanks.<br> <span class=3D""></span></blockquote><div><br><br></div><div>Hi,<br><br></d= iv><div>I tried to reproduce with 2.4.39, without success:<br><br>539ebd5e = conn=3D1000 fd=3D12 ACCEPT from IP=3D<a href=3D"http://127.0.0.1:56063">127= .0.0.1:56063</a> (IP=3D<a href=3D"http://0.0.0.0:5389">0.0.0.0:5389</a>)<br= > 539ebd5e conn=3D1000 op=3D0 BIND dn=3D"cn=3Dconfig" method=3D128<= br>539ebd5e conn=3D1000 op=3D0 BIND dn=3D"cn=3Dconfig" mech=3DSIM= PLE ssf=3D0<br>539ebd5e conn=3D1000 op=3D0 RESULT tag=3D97 err=3D0 text=3D<= br>539ebd5e conn=3D1000 op=3D1 MOD dn=3D"olcDatabase=3D{2}mdb,cn=3Dcon= fig"<br> 539ebd5e conn=3D1000 op=3D1 MOD attr=3DolcSyncrepl<br>539ebd5e olcSyncrepl:= value #0: Error: Malformed "syncrepl" line in slapd config file,= missing searchbase.<br>539ebd5e failed to add syncinfo<br>539ebd5e conn=3D= 1000 op=3D1 RESULT tag=3D103 err=3D80 text=3DError: Malformed "syncrep= l" line in slapd config file, missing searchbase<br> 539ebd5e conn=3D1000 op=3D2 UNBIND<br>539ebd5e conn=3D1000 fd=3D12 closed<b= r><br><br></div><div>So it seems there is no more issue with the latest Ope= nLDAP version.<br><br><br></div><div>Cl=C3=A9ment. <br></div></div></div></= div> --001a11c3c678534ebd04fbf0f3b5--

1 0

Re: (ITS#7876) LMDB compile issue on AIX 6.1
by fkruchio＠gmail.com 13 Jun '14

13 Jun '14

--089e013c62d425a67004fbb3c1e1 Content-Type: text/plain; charset=UTF-8 I installed gmake and lmdb compiled fine. Thank you Howard ! On Fri, Jun 13, 2014 at 5:29 PM, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#7876. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#7876) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#7876) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=7876 > > Please remember to retain your issue tracking number (ITS#7876) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --089e013c62d425a67004fbb3c1e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>I installed gmake and lmdb compiled fine.<br><br></di= v>Thank you Howard !<br><div><br></div></div><div class=3D"gmail_extra"><br= ><br><div class=3D"gmail_quote">On Fri, Jun 13, 2014 at 5:29 PM, <span dir= =3D"ltr"><<a href=3D"mailto:openldap-its@openldap.org" target=3D"_blank"= >openldap-its(a)openldap.org</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System. =C2=A0Your<br= > report has been assigned the tracking number ITS#7876.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers. =C2=A0They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message. =C2=A0Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#7876)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org">openldap-its(a)openldap.org</a>?subject=3D(ITS#7876)<br> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D787= 6" target=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D7876</a= ><br> <br> Please remember to retain your issue tracking number (ITS#7876)<br> on any further messages you send to us regarding this report. =C2=A0If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" ta= rget=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br></div> --089e013c62d425a67004fbb3c1e1--

1 0

Re: (ITS#7876) LMDB compile issue on AIX 6.1
by hyc＠symas.com 13 Jun '14

13 Jun '14

fkruchio(a)gmail.com wrote: > Full_Name: Frank Kruchio > Version: LMDB > OS: AIX 6.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.97.151.51) > > > Looking at cfengine 3.6 deployment on AIX and LMDB is a possible database to > use. > This is the error I receive when running make. > Has anyone managed to compile lmdb on AIX ? Use Gnumake. > > [root@p2aunx002]:/home/unixgrp/m014084/mdb/libraries/liblmdb # pwd > /home/unixgrp/m014084/mdb/libraries/liblmdb > [root@p2aunx002]:/home/unixgrp/m014084/mdb/libraries/liblmdb # make > gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast > -fPIC -c mdb.c > mdb.c: In function 'mdb_cursor_put': > mdb.c:6029: warning: dereferencing type-punned pointer will break > strict-aliasing rules > mdb.c:6029: warning: dereferencing type-punned pointer will break > strict-aliasing rules > mdb.c: In function 'mdb_node_shrink': > mdb.c:6691: warning: dereferencing type-punned pointer will break > strict-aliasing rules > mdb.c:6691: warning: dereferencing type-punned pointer will break > strict-aliasing rules > mdb.c: In function 'mdb_xcursor_init1': > mdb.c:6765: warning: dereferencing type-punned pointer will break > strict-aliasing rules > mdb.c:6765: warning: dereferencing type-punned pointer will break > strict-aliasing rules > gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast > -fPIC -c midl.c > ar rs liblmdb.a mdb.o midl.o > ar: creating an archive file liblmdb.a > gcc -pthread -shared -o liblmdb.so mdb.o midl.o > gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast > -c mdb_stat.c > gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast > mdb_stat.c -o mdb_stat > ld: 0711-317 ERROR: Undefined symbol: .mdb_env_create > ld: 0711-317 ERROR: Undefined symbol: .mdb_env_set_maxdbs > ld: 0711-317 ERROR: Undefined symbol: .mdb_env_open > ld: 0711-317 ERROR: Undefined symbol: .mdb_reader_list > ld: 0711-317 ERROR: Undefined symbol: .mdb_reader_check > ld: 0711-317 ERROR: Undefined symbol: .mdb_txn_begin > ld: 0711-317 ERROR: Undefined symbol: .mdb_cursor_open > ld: 0711-317 ERROR: Undefined symbol: .mdb_stat > ld: 0711-317 ERROR: Undefined symbol: .mdb_cursor_get > ld: 0711-317 ERROR: Undefined symbol: .mdb_env_stat > ld: 0711-317 ERROR: Undefined symbol: .mdb_env_info > ld: 0711-317 ERROR: Undefined symbol: .mdb_strerror > ld: 0711-317 ERROR: Undefined symbol: .mdb_env_close > ld: 0711-317 ERROR: Undefined symbol: .mdb_cursor_close > ld: 0711-317 ERROR: Undefined symbol: .mdb_dbi_open > ld: 0711-317 ERROR: Undefined symbol: .mdb_dbi_close > ld: 0711-317 ERROR: Undefined symbol: .mdb_txn_abort > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. > collect2: ld returned 8 exit status > make: The error code from the last command is 1. > > > Stop. > > -- -- 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#7876) LMDB compile issue on AIX 6.1
by fkruchio＠gmail.com 13 Jun '14

13 Jun '14

Full_Name: Frank Kruchio Version: LMDB OS: AIX 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.97.151.51) Looking at cfengine 3.6 deployment on AIX and LMDB is a possible database to use. This is the error I receive when running make. Has anyone managed to compile lmdb on AIX ? [root@p2aunx002]:/home/unixgrp/m014084/mdb/libraries/liblmdb # pwd /home/unixgrp/m014084/mdb/libraries/liblmdb [root@p2aunx002]:/home/unixgrp/m014084/mdb/libraries/liblmdb # make gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -fPIC -c mdb.c mdb.c: In function 'mdb_cursor_put': mdb.c:6029: warning: dereferencing type-punned pointer will break strict-aliasing rules mdb.c:6029: warning: dereferencing type-punned pointer will break strict-aliasing rules mdb.c: In function 'mdb_node_shrink': mdb.c:6691: warning: dereferencing type-punned pointer will break strict-aliasing rules mdb.c:6691: warning: dereferencing type-punned pointer will break strict-aliasing rules mdb.c: In function 'mdb_xcursor_init1': mdb.c:6765: warning: dereferencing type-punned pointer will break strict-aliasing rules mdb.c:6765: warning: dereferencing type-punned pointer will break strict-aliasing rules gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -fPIC -c midl.c ar rs liblmdb.a mdb.o midl.o ar: creating an archive file liblmdb.a gcc -pthread -shared -o liblmdb.so mdb.o midl.o gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -c mdb_stat.c gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast mdb_stat.c -o mdb_stat ld: 0711-317 ERROR: Undefined symbol: .mdb_env_create ld: 0711-317 ERROR: Undefined symbol: .mdb_env_set_maxdbs ld: 0711-317 ERROR: Undefined symbol: .mdb_env_open ld: 0711-317 ERROR: Undefined symbol: .mdb_reader_list ld: 0711-317 ERROR: Undefined symbol: .mdb_reader_check ld: 0711-317 ERROR: Undefined symbol: .mdb_txn_begin ld: 0711-317 ERROR: Undefined symbol: .mdb_cursor_open ld: 0711-317 ERROR: Undefined symbol: .mdb_stat ld: 0711-317 ERROR: Undefined symbol: .mdb_cursor_get ld: 0711-317 ERROR: Undefined symbol: .mdb_env_stat ld: 0711-317 ERROR: Undefined symbol: .mdb_env_info ld: 0711-317 ERROR: Undefined symbol: .mdb_strerror ld: 0711-317 ERROR: Undefined symbol: .mdb_env_close ld: 0711-317 ERROR: Undefined symbol: .mdb_cursor_close ld: 0711-317 ERROR: Undefined symbol: .mdb_dbi_open ld: 0711-317 ERROR: Undefined symbol: .mdb_dbi_close ld: 0711-317 ERROR: Undefined symbol: .mdb_txn_abort ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make: The error code from the last command is 1. Stop.

1 0

Re: (ITS#7875) lmdb MDB_GET_BOTH unexpected success
by hyc＠symas.com 11 Jun '14

11 Jun '14

mail(a)arnedebruijn.nl wrote: > Full_Name: Arne de Bruijn > Version: mdb.master a93810c > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (94.210.130.16) > > > MDB_GET_BOTH seems to unexpectedly return success if a data-value before the > first data-value for a key is requested. Thanks for the report. This appears to have been broken due to commit 18a07eb7c2dc33372455a6040984cd6b699b41a5 for ITS#7681. Fixed now in mdb.master > > The example program sets 1:b and 1:c and requests 1:a. It prints: > get_both: key=1 val=b > > While I would expect: > get_both: err=MDB_NOTFOUND: No matching key/data pair found > > (curiously it works when it only sets 1:b) > > #include <stdlib.h> > #include <stdio.h> > #include <string.h> > #include <unistd.h> > #include "lmdb.h" > > void set_val(MDB_val *v, char *s) { > v->mv_size = strlen(s); > v->mv_data = s; > } > > int main() { > int rc; > MDB_env *menv = NULL; > MDB_dbi mdbi; > MDB_txn *mtxn = NULL; > MDB_val key, val; > MDB_cursor *mc; > > if ((rc = mdb_env_create(&menv))) > goto err; > if ((rc = unlink("testdb"))) > goto err; > if ((rc = mdb_env_open(menv, "testdb", MDB_NOSUBDIR, 0666))) > goto err; > if ((rc = mdb_txn_begin(menv, NULL, 0, &mtxn))) > goto err; > if ((rc = mdb_dbi_open(mtxn, NULL, MDB_DUPSORT | MDB_CREATE, &mdbi))) > goto err; > set_val(&key, "1"); > set_val(&val, "b"); > if ((rc = mdb_put(mtxn, mdbi, &key, &val, 0))) > goto err; > set_val(&key, "1"); > set_val(&val, "c"); > if ((rc = mdb_put(mtxn, mdbi, &key, &val, 0))) > goto err; > > if ((rc = mdb_cursor_open(mtxn, mdbi, &mc))) > goto err; > > set_val(&key, "1"); > set_val(&val, "a"); > rc = mdb_cursor_get(mc, &key, &val, MDB_GET_BOTH); > if (rc) > printf("get_both: err=%s\n", mdb_strerror(rc)); > else > printf("get_both: key=%.*s val=%.*s\n", key.mv_size, (char *)key.mv_data, > val.mv_size, (char *)val.mv_data); > > mdb_cursor_close(mc); > > if ((rc = mdb_txn_commit(mtxn))) { > mdb_dbi_close(menv, mdbi); > goto err; > } > mdb_env_close(menv); > return 0; > err: > if (mtxn) > mdb_txn_abort(mtxn); > if (menv) > mdb_env_close(menv); > fprintf(stderr, "Error: %s\n", mdb_strerror(rc)); > return 1; > } > > -- -- 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#7875) lmdb MDB_GET_BOTH unexpected success
by mail＠arnedebruijn.nl 11 Jun '14

11 Jun '14

Full_Name: Arne de Bruijn Version: mdb.master a93810c OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.210.130.16) MDB_GET_BOTH seems to unexpectedly return success if a data-value before the first data-value for a key is requested. The example program sets 1:b and 1:c and requests 1:a. It prints: get_both: key=1 val=b While I would expect: get_both: err=MDB_NOTFOUND: No matching key/data pair found (curiously it works when it only sets 1:b) #include <stdlib.h> #include <stdio.h> #include <string.h> #include <unistd.h> #include "lmdb.h" void set_val(MDB_val *v, char *s) { v->mv_size = strlen(s); v->mv_data = s; } int main() { int rc; MDB_env *menv = NULL; MDB_dbi mdbi; MDB_txn *mtxn = NULL; MDB_val key, val; MDB_cursor *mc; if ((rc = mdb_env_create(&menv))) goto err; if ((rc = unlink("testdb"))) goto err; if ((rc = mdb_env_open(menv, "testdb", MDB_NOSUBDIR, 0666))) goto err; if ((rc = mdb_txn_begin(menv, NULL, 0, &mtxn))) goto err; if ((rc = mdb_dbi_open(mtxn, NULL, MDB_DUPSORT | MDB_CREATE, &mdbi))) goto err; set_val(&key, "1"); set_val(&val, "b"); if ((rc = mdb_put(mtxn, mdbi, &key, &val, 0))) goto err; set_val(&key, "1"); set_val(&val, "c"); if ((rc = mdb_put(mtxn, mdbi, &key, &val, 0))) goto err; if ((rc = mdb_cursor_open(mtxn, mdbi, &mc))) goto err; set_val(&key, "1"); set_val(&val, "a"); rc = mdb_cursor_get(mc, &key, &val, MDB_GET_BOTH); if (rc) printf("get_both: err=%s\n", mdb_strerror(rc)); else printf("get_both: key=%.*s val=%.*s\n", key.mv_size, (char *)key.mv_data, val.mv_size, (char *)val.mv_data); mdb_cursor_close(mc); if ((rc = mdb_txn_commit(mtxn))) { mdb_dbi_close(menv, mdbi); goto err; } mdb_env_close(menv); return 0; err: if (mtxn) mdb_txn_abort(mtxn); if (menv) mdb_env_close(menv); fprintf(stderr, "Error: %s\n", mdb_strerror(rc)); return 1; }

1 0

Re: (ITS#7874) Replication Debian & Ubuntu ( PROBLEM )
by quanah＠zimbra.com 05 Jun '14

05 Jun '14

--On Thursday, June 05, 2014 11:40 AM +0000 lisivoandre(a)gmail.com wrote: > ____________________________________________x____________________________ > ____________ > > Changed: > olcServerID: 001 ldaps://ldap01.example.tld > For: > olcServerID: 001 ldap://<IP> > ________________________________________________________ It was all the > changes i made! a) The URI in olcServerID *must* match the URI used to start slapd (the -h option to slapd) b) ldaps/startTLS do not work with a server IP unless you've added the IP to subjectAltNames c) The Debian/Ubuntu builds are utterly unusable, you need to get a sane build. In any case, this is not a bug report. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7874) Replication Debian & Ubuntu ( PROBLEM )
by lisivoandre＠gmail.com 05 Jun '14

05 Jun '14

Full_Name: André Campos Version: 2.4.31 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.136.194.93) Hi i am having problems with the replication i am using Ubuntu 12.04 LTS to connect to a Debian, the master. With the help from this tutorial: http://grungelabs.com/guides/2012/06/08/ha-openldap-debian/, i did some changes to the overall. I didn't configure the ssl but i did Import the schemata and add memberof. The commands like: ldapmodify -Y EXTERNAL -H ldapi:/// -D olcDatabase={1}hdb,cn=config -f ./repl_db_slave_auth.ldif For: ldapmodify -f repl_master.ldif -D cn=admin,cn=config -x -W ____________________________________________x________________________________________ Changed: olcServerID: 001 ldaps://ldap01.example.tld For: olcServerID: 001 ldap://<IP> ________________________________________________________ It was all the changes i made! But here is the problem i made all the tutorial in the Debian (master) and the last part mean to Ubuntu (slave or ldap02) and when i restart it's ok in the slave but in the master when i restart slapd it gets an error and when i go to the logs, here's the following: Jun 5 10:56:14 controller slapd[11221]: @(#) $OpenLDAP: slapd (Apr 23 2013 12:16:04) $#012#011root@lupin:/tmp/buildd/openldap-2.4.31/debian/build/servers/slapd Jun 5 10:56:14 controller slapd[11221]: read_config: no serverID / URL match found. Check slapd -h arguments. Jun 5 10:56:14 controller slapd[11221]: slapd stopped. Jun 5 10:56:14 controller slapd[11221]: connections_destroy: nothing to destroy. _______________________________________x____________________________________________ I don't know what to do so what do i do?

1 0

(ITS#7873) slapo-refint interferes with cn=config
by hyc＠OpenLDAP.org 04 Jun '14

04 Jun '14

Full_Name: Howard Chu Version: 2.4.39 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc The refint overlay performs its referential integrity updates in a separately queued thread. On a large database the necessary updates may take a long time, and currently the refint_qtask doesn't check for pending cn=config pause requests. Fix coming shortly.

1 0

(ITS#7872) slapd-mdb memory leak in mdb_entry_get
by hyc＠OpenLDAP.org 04 Jun '14

04 Jun '14

Full_Name: Howard Chu Version: 2.4.39 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Actually the leak is in dn2entry but it only occurs when called from mdb_entry_get. A fix is coming shortly.

1 0

Re: (ITS#6970) OpenLDAP 2.4.25 MemberOf + AutoGroup user has stale "memberof" attributes for target group after removal from trigger group
by ryan＠nardis.ca 04 Jun '14

04 Jun '14

Hi, The last comments on this ITS mentioned crashes or deadlocks when using autogroup and memberof together. I tried this today with git master on both mdb and hdb backends. Adding a new entry that triggers an autogroup member to be added: I don't get a crash or deadlock, but the new entry doesn't have a memberOf attribute. It looks like the internal Modify adding the member happens before the Add completes, so memberof tries to add memberOf to an entry that doesn't exist yet. Changing autogroup to trigger on an alteration to an existing entry, for example addition of a specific attribute or auxiliary objectClass: with mdb this works and the memberOf attribute is added; with hdb I get the same deadlock Landry Breuil already reported. Looks like a recursive deadlock on the same thread. I think those problems are both different from the one this ITS is about, though. Maybe they should be filed separately. I also confirmed the problem originally reported on current git master, and the analysis sounds right, but I haven't had time to think through the proposed solution fully. I'm not totally sure whether it's autogroup or memberof that actually needs fixing. Maybe both. cheers, Ryan

1 0

Re: (ITS#7871) slapcat ldif-wrap option produced wrong column length
by hyc＠symas.com 04 Jun '14

04 Jun '14

mwarren(a)symas.com wrote: > Full_Name: Mark Warren > Version: 2.4.39 > OS: Debian 6 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (72.35.133.119) > > > It appears that the slapcat option '-o ldif-wrap=n' is not properly followed. > > e.g, this: > > slapcat -o ldif-wrap=30 > > will produce a file with 32 columns not including the newline character. Yes, we already detailed this in ITS#7859 followup #1. -- -- 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#7871) slapcat ldif-wrap option produced wrong column length
by mwarren＠symas.com 04 Jun '14

04 Jun '14

Full_Name: Mark Warren Version: 2.4.39 OS: Debian 6 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.35.133.119) It appears that the slapcat option '-o ldif-wrap=n' is not properly followed. e.g, this: slapcat -o ldif-wrap=30 will produce a file with 32 columns not including the newline character. Regards, Mark

1 0

(ITS#7870) slapd-mdb slapcat failure
by hyc＠OpenLDAP.org 04 Jun '14

04 Jun '14

Full_Name: Howard Chu Version: 2.4.39 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc If an index was configured in slapd.conf but not created yet (e.g. slapindex wasn't run) then slapcat will fail because it tried to open the index DB in read-only mode and it doesn't exist yet. slapcat shouldn't even bother to open the index DBs since it doesn't use them. Fix coming shortly.

1 0

(ITS#7869) [PATCH] contrib passwd/apr1 do_phk_hash arguments
by ryan＠nardis.ca 02 Jun '14

02 Jun '14

Full_Name: Ryan Tandy Version: master/33e12f4 RE24/b000d95 OS: Debian unstable URL: Submission from: (NULL) (24.68.121.206) Hi, The apr1 passwd plugin calls do_phk_hash with the arguments in the wrong order, so the digest updates are done in a different order than md5crypt does. The following patch fixes that, restoring compatibility with existing htpasswd files. However, existing {APR1} hashes that were generated while the bug existed are going to be broken... I'm not sure what to do about that. :/ thanks, Ryan >From f9ad46e3c8264ffa1420aa3b24cfc69cae7bed65 Mon Sep 17 00:00:00 2001 From: Ryan Tandy <ryan(a)nardis.ca> Date: Sun, 1 Jun 2014 22:41:23 -0700 Subject: [PATCH] contrib passwd/apr1 fix do_phk_hash arguments --- contrib/slapd-modules/passwd/apr1.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/slapd-modules/passwd/apr1.c b/contrib/slapd-modules/passwd/apr1.c index ce7b8c7..463d8d1 100644 --- a/contrib/slapd-modules/passwd/apr1.c +++ b/contrib/slapd-modules/passwd/apr1.c @@ -143,7 +143,7 @@ static int chk_phk( salt.bv_val = (char *) &orig_pass[sizeof(digest)]; salt.bv_len = rc - sizeof(digest); - do_phk_hash(cred, magic, &salt, digest); + do_phk_hash(cred, &salt, magic, digest); if (text) *text = NULL; @@ -197,7 +197,7 @@ static int hash_phk( for (n = 0; n < salt.bv_len; n++) salt.bv_val[n] = apr64[salt.bv_val[n] % (sizeof(apr64) - 1)]; - do_phk_hash(passwd, magic, &salt, digest_buf); + do_phk_hash(passwd, &salt, magic, digest_buf); if (text) *text = NULL; -- 2.0.0

1 0

(ITS#7868) Sock overlay segfault when reading sockname from configfile
by orcus＠pwr.wroc.pl 02 Jun '14

02 Jun '14

Full_Name: Daniel Dobrijalowski Version: 2.4.39 OS: 2.6.32-431.17.1.el6.centos.plus.x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (156.17.1.3) Hi, servers/slapd/config.c: line 477: if ( *(char **)ptr ) ptr is NULL so it triggers SIGSEGV line: 461: ptr = c->bi->bi_private; bi_private is NULL My knowledge of openldap internals is to weak to find where and if bi_private should be initialized in this case. Steps to reproduce: After downloading openldap-2.4.39 and configuring it with options: ./configure --prefix=/usr/ --enable-slapd --enable-overlays --enable-bdb --enable-meta --enable-monitor --enable-sock --enable-crypt --enable-cleartext --enable-ldap --with-tls=openssl --sysconfdir=/etc I have added only slapo-sock related options at the end of default slapd.conf: overlay sock extensions peername socketpath "/tmp/ldap.sock" sockops bind sockresps result

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs