- openldap-bugs - openldap.org

Re: (ITS#5976) seg fault problem starting with version 2.1.14
by quanah＠zimbra.com 25 Feb '09

25 Feb '09

--On Wednesday, February 25, 2009 8:24 PM +0000 aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.1.15 > OS: Red Hat Linux E5 > URL: > Submission from: (NULL) (130.215.36.68) > > > I somehow missed installing 2.1.14, and was still running 2.1.13. I > found that 2.1.15 did not run on one of my servers (but worked on the > other 2). Looking back, 2.1.14 had the same problem. 2.1.13, compiled > and linked again on that same client still worked ok, so it doesn't > appear that libraries went sour. The failure is on a gssapi syncrepl > client on an opteron. The gssapi syncrepl client on Intel works ok. The > master appears to work ok, too. The ldap server was running on > appliance4 and was accessing the master on appliance1. OpenLDAP 2.1? That's years ancient, and no longer supported. Use a modern supported release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5976) seg fault problem starting with version 2.1.14
by aej＠wpi.edu 25 Feb '09

25 Feb '09

Full_Name: Allan E. Johannesen Version: 2.1.15 OS: Red Hat Linux E5 URL: Submission from: (NULL) (130.215.36.68) I somehow missed installing 2.1.14, and was still running 2.1.13. I found that 2.1.15 did not run on one of my servers (but worked on the other 2). Looking back, 2.1.14 had the same problem. 2.1.13, compiled and linked again on that same client still worked ok, so it doesn't appear that libraries went sour. The failure is on a gssapi syncrepl client on an opteron. The gssapi syncrepl client on Intel works ok. The master appears to work ok, too. The ldap server was running on appliance4 and was accessing the master on appliance1. When starting it under debugging -d-1, I got to this: ldap_sasl_interactive_bind_s: user selected: gssapi ldap_int_sasl_bind: gssapi ldap_int_sasl_open: host=appliance1.wpi.edu Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x43377940 (LWP 21161)] ber_get_tag (ber=0x433762c0) at decode.c:110 110 tag = *(unsigned char *)ber->ber_ptr; (gdb) where #0 ber_get_tag (ber=0x433762c0) at decode.c:110 #1 0x0000000000506bdb in ber_skip_tag (ber=0x433762c0, len=0x433763f8) at decode.c:169 #2 0x0000000000507653 in ber_peek_tag (ber=0x433762c0, len=0x433763f8) at decode.c:228 #3 0x0000000000502794 in ldap_X509dn2bv (x509_name=<value optimized out>, bv=0x43376520, func=0, flags=0) at tls2.c:1016 #4 0x0000000000502e6b in ldap_pvt_tls_get_my_dn (s=<value optimized out>, dn=0x43376520, func=0, flags=0) at tls2.c:876 #5 0x00000000004ebd8f in ldap_int_sasl_bind (ld=0x16c76810, dn=0x0, mechs=0x1699c490 "gssapi", sctrls=0x0, cctrls=0x0, flags=2, interact=0x4dc160 <lutil_sasl_interact>, defaults=0x16d1c370) at cyrus.c:479 #6 0x00000000004ed41c in ldap_sasl_interactive_bind_s (ld=0x16c76810, dn=0x0, mechs=0x1699c490 "gssapi", serverControls=0x0, clientControls=0x0, flags=2, interact=0x4dc160 <lutil_sasl_interact>, defaults=0x16d1c370) at sasl.c:464 #7 0x000000000041584b in slap_client_connect (ldp=0x1699d120, sb=0x1699cf20) at config.c:1764 #8 0x0000000000479dfa in do_syncrepl (ctx=0x43376d70, arg=<value optimized out>) at syncrepl.c:560 #9 0x00000000004e588a in ldap_int_thread_pool_wrapper (xpool=0x1693a410) at tpool.c:663 #10 0x0000003dedc06367 in start_thread () from /lib64/libpthread.so.0 #11 0x0000003ded0d30ad in clone () from /lib64/libc.so.6

1 0

Re: (ITS#5975) minor issue with slapd.conf manpage
by ando＠sys-net.it 25 Feb '09

25 Feb '09

eric(a)huss.org wrote: > There appears to be a couple slightly incorrect statements in the slapd.conf > manpage. It says that the argsfile and pidfile values are used "if started > without the debugging command line option". However, it doesn't appear to make > any difference whether or not you use the -d option with slapd. > > This phrasing could be replaced with something that indicates if it is not > specified, the file will not be created. Correct. However I'm not sure whether the man page or the code needs to be fixed. I'm open to suggestions. I'm inclined towards following the man page, as the use of -d implies one may not need the pid, and knows the args. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org 25 Feb '09

25 Feb '09

On Feb 25, 2009, at 1:42 AM, hyc(a)symas.com wrote: > The -compat code is LGPL. I'm considering copying the ciphersuite > handling and > a few other pieces out of there, directly into our tree. There's a > lot of > other baggage in the compat library we don't need, and there's some > OpenSSL > emulation that would interfere with the NSS code we already have. > Any problem > with excerpting the bits we need? I would need to take a very careful look at this. In general, the answer is "NO", don't bring in LGPL code into our primary code base (standalone LGPL in contrib is another matter). -- Kurt

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 25 Feb '09

25 Feb '09

hyc(a)symas.com wrote: > Also, the patch uses the OpenSSL-compatibility stuff in NSS. The current code > in HEAD uses NSS natively, and I'd prefer not to have the -compat dependency > as well. That's a key requirement to me personally, because otherwise it will > not interoperate with Mozilla/Seamonkey, and right now that's my primary goal > for this work. The -compat code is LGPL. I'm considering copying the ciphersuite handling and a few other pieces out of there, directly into our tree. There's a lot of other baggage in the compat library we don't need, and there's some OpenSSL emulation that would interfere with the NSS code we already have. Any problem with excerpting the bits we need? > It's been a few months since I last looked at this and it took me a while to > remember all the issues surrounding it... > > There are two major problems with the current MozNSS support in HEAD: > 1) It does no initialization of its own. This works with Seamonkey/Thunderbird > because the main app has already initialized the NSS library; libldap just > uses the state that's already there. Code to initialize properly when NSS > hasn't already been initialized still needs to be written. > 2) It cannot shutdown safely. This is a weakness in the NSS API that was > discussed at length in the Mozilla newsgroups. Unfortunately that discussion > went nowhere. (The NSS_Shutdown() function tears down the library > unconditionally; if there were multiple callers of the library and one of them > shuts down because it's going away, all of the other callers lose the library > too.) It appears that not much progress has been made on the latter problem. Here's a relevant wiki http://wiki.mozilla.org/NSS_Shared_DB_And_LINUX Unfortunately this aspect of NSS is still too broken for it to be used safely in libldap, when other apps also use NSS directly. There's still no technical advantage to using this over OpenSSL, and there's still a significant usability/app-safety disadvantage to adopting it. (GnuTLS at least offers TLS1.2 support, which neither OpenSSL or MozNSS do yet. Both OpenSSL and MozNSS have FIPS-140 validations, but FIPS mode is incompatible with the way most existing software uses these libraries, so it's kind of a moot point.) -- -- 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#5975) minor issue with slapd.conf manpage
by eric＠huss.org 24 Feb '09

24 Feb '09

Full_Name: Eric Huss Version: 2.4.15 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.81.244.185) There appears to be a couple slightly incorrect statements in the slapd.conf manpage. It says that the argsfile and pidfile values are used "if started without the debugging command line option". However, it doesn't appear to make any difference whether or not you use the -d option with slapd. This phrasing could be replaced with something that indicates if it is not specified, the file will not be created.

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 24 Feb '09

24 Feb '09

Kurt(a)OpenLDAP.org wrote: > On Feb 24, 2009, at 1:01 PM, richm(a)stanfordalumni.org wrote: >> Perhaps a better question is - how would you like it to work? > I prefer that we leave the builder with as freedom as possible. Right, that makes the most sense. >> I'm assuming there must be some way specify which crypto you want to >> build >> openldap with - is that a configure option? > > Presently there is: > --with-tls=[auto,openssl,gnutls] > > I assume we'd just add an 'nss' option to the above. However, Howard > might have other things in mind. Yes (but the option will be "moznss"). >>>> Note >>>> that both NSPR and NSS support pkg-config >>> Here would be to ensure that the proper pkg-config is in the PATH. >>> >>> Of course, pkg-config stuff gets stuff into the environment in some >>> fixed order, which does take away some freedom from the builder. I >>> guess the builder can always manually adjust the order (by providing >>> CPPFLAGS, etc., directly) and then provide a pkg_config which does >>> little. So the freedom is there, just harder to take advantage of. >> The original patch - >> ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch - >> assumes the use of pkg-config - I suppose that is not sufficient. > > My only concern would be whether or not pkg-config use here is > specific to a particular 3rd party packaging of NSS versus something > available with all installs of NSS. I currently build against a copy of NSS in my Mozilla build tree. There's nothing installed with pkg-config. I would like to avoid a dependency on pkg-config. Also, the patch uses the OpenSSL-compatibility stuff in NSS. The current code in HEAD uses NSS natively, and I'd prefer not to have the -compat dependency as well. That's a key requirement to me personally, because otherwise it will not interoperate with Mozilla/Seamonkey, and right now that's my primary goal for this work. It's been a few months since I last looked at this and it took me a while to remember all the issues surrounding it... There are two major problems with the current MozNSS support in HEAD: 1) It does no initialization of its own. This works with Seamonkey/Thunderbird because the main app has already initialized the NSS library; libldap just uses the state that's already there. Code to initialize properly when NSS hasn't already been initialized still needs to be written. 2) It cannot shutdown safely. This is a weakness in the NSS API that was discussed at length in the Mozilla newsgroups. Unfortunately that discussion went nowhere. (The NSS_Shutdown() function tears down the library unconditionally; if there were multiple callers of the library and one of them shuts down because it's going away, all of the other callers lose the library too.) Another problem I've had in integrating is that the documentation is out of date with the code - the docs recommend certain APIs and practices that are actually deprecated in the actual code. This has led down a lot of blind alleys/dead ends that could otherwise have been avoided... > I'll be leaving the actual technical review of your patch to Howard or > other active committers. -- -- 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#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org 24 Feb '09

24 Feb '09

On Feb 24, 2009, at 1:01 PM, richm(a)stanfordalumni.org wrote: > Kurt Zeilenga wrote: >> >> On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote: >> >>> Kurt(a)OpenLDAP.org wrote: >>>> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: >>>> >>>> >>>>> I'm still uncertain about how configure should detect the NSS >>>>> header >>>>> files >>>>> though; they are not in any standardized location yet AFAICS. >>>>> >>>> >>>> Like with other things, I would assume the environment to be >>>> adjusted >>>> to find the right NSS prior to running configure. >>>> >>> I'm not sure I understand what you mean by "environment to be >>> adjusted" >> >> CPPFLAGS, CFLAGS, ... and PATH environmental variables. >> >>> >>> - How does openldap detect the header files for other components? >> >> autoconf is used, which uses the compiler to check if necessary >> headers are there, with the (additional to those built into the >> compiler) header path specified via CPPFLAGS. >> >> The idea here is to give the builder the freedom over which header >> directories are searched, and the order in which they are searched. > What's the usual way that openldap does this for packages installed in > non-standard locations e.g. if I want to have my own private build of > cyrus-sasl? Is it up to the user to specify > CPPFLAGS=-I/path/to/nonstd/sasl/include and > LDFLAGS=-L/path/to/nonstd/lib ? Yes. > Does openldap configure have a > --with-sasl=/path/to/nonstd/sasl option? No. Because CPPFLAGS and LDFLAGS mechanism exists and provides more control to the builder. > > > Perhaps a better question is - how would you like it to work? I prefer that we leave the builder with as freedom as possible. > I'm assuming there must be some way specify which crypto you want to > build > openldap with - is that a configure option? Presently there is: --with-tls=[auto,openssl,gnutls] I assume we'd just add an 'nss' option to the above. However, Howard might have other things in mind. > >> >>> Note >>> that both NSPR and NSS support pkg-config >> >> Here would be to ensure that the proper pkg-config is in the PATH. >> >> Of course, pkg-config stuff gets stuff into the environment in some >> fixed order, which does take away some freedom from the builder. I >> guess the builder can always manually adjust the order (by providing >> CPPFLAGS, etc., directly) and then provide a pkg_config which does >> little. So the freedom is there, just harder to take advantage of. > The original patch - > ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch - > assumes the use of pkg-config - I suppose that is not sufficient. My only concern would be whether or not pkg-config use here is specific to a particular 3rd party packaging of NSS versus something available with all installs of NSS. I'll be leaving the actual technical review of your patch to Howard or other active committers. -- Kurt

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by richm＠stanfordalumni.org 24 Feb '09

24 Feb '09

Kurt Zeilenga wrote: > > On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: >>> >>> >>>> I'm still uncertain about how configure should detect the NSS header >>>> files >>>> though; they are not in any standardized location yet AFAICS. >>>> >>> >>> Like with other things, I would assume the environment to be adjusted >>> to find the right NSS prior to running configure. >>> >> I'm not sure I understand what you mean by "environment to be adjusted" > > CPPFLAGS, CFLAGS, ... and PATH environmental variables. > >> >> - How does openldap detect the header files for other components? > > autoconf is used, which uses the compiler to check if necessary > headers are there, with the (additional to those built into the > compiler) header path specified via CPPFLAGS. > > The idea here is to give the builder the freedom over which header > directories are searched, and the order in which they are searched. What's the usual way that openldap does this for packages installed in non-standard locations e.g. if I want to have my own private build of cyrus-sasl? Is it up to the user to specify CPPFLAGS=-I/path/to/nonstd/sasl/include and LDFLAGS=-L/path/to/nonstd/lib ? Does openldap configure have a --with-sasl=/path/to/nonstd/sasl option? Perhaps a better question is - how would you like it to work? I'm assuming there must be some way specify which crypto you want to build openldap with - is that a configure option? > >> Note >> that both NSPR and NSS support pkg-config > > Here would be to ensure that the proper pkg-config is in the PATH. > > Of course, pkg-config stuff gets stuff into the environment in some > fixed order, which does take away some freedom from the builder. I > guess the builder can always manually adjust the order (by providing > CPPFLAGS, etc., directly) and then provide a pkg_config which does > little. So the freedom is there, just harder to take advantage of. The original patch - ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch - assumes the use of pkg-config - I suppose that is not sufficient. > > -- Kurt > >

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org 24 Feb '09

24 Feb '09

On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote: > Kurt(a)OpenLDAP.org wrote: >> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: >> >> >>> I'm still uncertain about how configure should detect the NSS header >>> files >>> though; they are not in any standardized location yet AFAICS. >>> >> >> Like with other things, I would assume the environment to be adjusted >> to find the right NSS prior to running configure. >> > I'm not sure I understand what you mean by "environment to be > adjusted" CPPFLAGS, CFLAGS, ... and PATH environmental variables. > > - How does openldap detect the header files for other components? autoconf is used, which uses the compiler to check if necessary headers are there, with the (additional to those built into the compiler) header path specified via CPPFLAGS. The idea here is to give the builder the freedom over which header directories are searched, and the order in which they are searched. > Note > that both NSPR and NSS support pkg-config Here would be to ensure that the proper pkg-config is in the PATH. Of course, pkg-config stuff gets stuff into the environment in some fixed order, which does take away some freedom from the builder. I guess the builder can always manually adjust the order (by providing CPPFLAGS, etc., directly) and then provide a pkg_config which does little. So the freedom is there, just harder to take advantage of. -- Kurt

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by richm＠stanfordalumni.org 24 Feb '09

24 Feb '09

Kurt(a)OpenLDAP.org wrote: > On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: > > >> I'm still uncertain about how configure should detect the NSS header >> files >> though; they are not in any standardized location yet AFAICS. >> > > Like with other things, I would assume the environment to be adjusted > to find the right NSS prior to running configure. > I'm not sure I understand what you mean by "environment to be adjusted" - How does openldap detect the header files for other components? Note that both NSPR and NSS support pkg-config > -- Kurt > > > > >

1 0

Re: (ITS#5974) libldap not consistently using namespaces
by hyc＠symas.com 24 Feb '09

24 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> Since all those functions are not meant to be exposed, I guess fixing >> the (mis)use of the ldap namespace should not create issues. > Wait for 2.5 to break binary compatibility. If a function is there and > is useful, people will dig it out and use it. Agreed. But we can probably fix slapd's use of ldap_int APIs. > Just like back-bdb used > (uses?) some internal Berkeley DB locking function. (Not any more...) -- -- 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#5974) libldap not consistently using namespaces
by ando＠sys-net.it 24 Feb '09

24 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> Since all those functions are not meant to be exposed, I guess fixing >> the (mis)use of the ldap namespace should not create issues. > > Wait for 2.5 to break binary compatibility. Sure, no hurry. I'm just getting a bit confused when digging into very nested libldap stuff... > If a function is there and > is useful, people will dig it out and use it. That's probably my last concern, though :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5974) libldap not consistently using namespaces
by h.b.furuseth＠usit.uio.no 24 Feb '09

24 Feb '09

ando(a)sys-net.it writes: > Since all those functions are not meant to be exposed, I guess fixing > the (mis)use of the ldap namespace should not create issues. Wait for 2.5 to break binary compatibility. If a function is there and is useful, people will dig it out and use it. Just like back-bdb used (uses?) some internal Berkeley DB locking function. -- Hallvard

1 0

(ITS#5974) libldap not consistently using namespaces
by ando＠sys-net.it 24 Feb '09

24 Feb '09

Full_Name: Pierangelo Masarati Version: any OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando There are quite a few local functions with no namespace (e.g. re_encode_request()), but what seems to be mostly incorrect is ldap namespace pollution (e.g. ldap_chase_v3referrals()). Finally, there are quite a few occurrences of ldap_int_tls_config() used outside libldap (in slapd). Since all those functions are not meant to be exposed, I guess fixing the (mis)use of the ldap namespace should not create issues. p.

1 0

(ITS#5973) Syncrepl can update more than one csn value
by rein＠OpenLDAP.org 24 Feb '09

24 Feb '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein Syncrepl can update more than one csn value in one operation, but only one can be passed to syncprov in the csn queue. Syncprov should instead pick the updated values from the modify operation. A patch that fixes this is coming. This patch depends on the ITS#5972 patch, and is required for the new test058 to succeed. Rein Tollevik Basefarm AS

1 0

(ITS#5972) Send newCookie sync info messages
by rein＠OpenLDAP.org 24 Feb '09

24 Feb '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein When syncprov updates its local contextCSN value after some modification took place this update will not be propagated to consumers that doesn't receive the updated entry (it could fail to match the filter, or access control could prevent it). In this case, the consumer will have an old contextCSN value although its content is up to date. The provider should in this case send a newcookie sync info message to the consumer with its updated contextCSN value. A patch that implements this is coming. This patch is required for the new test058 to succeed. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5967) build failure with openssl : error: structure has no member named `ldo_tls_crlcheck'
by quanah＠zimbra.com 24 Feb '09

24 Feb '09

--On Tuesday, February 24, 2009 11:11 AM +0100 Adrien Futschik <adrien.futschik(a)atosorigin.com> wrote: > I confirme that it was a problem with OpenLDAP 2.4.14, it now works fine > with OpenLDAP 2.4.15. > > I guess this ITS is a "duplicate" of ITS#5955 That would seem to indicate that your various settings you pass on to configure are incorrect in some manner then, since the changes made only affect builds of OpenLDAP that would be compiled against GnuTLS, not OpenSSL. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5967) build failure with openssl : error: structure has no member named `ldo_tls_crlcheck'
by adrien.futschik＠atosorigin.com 24 Feb '09

24 Feb '09

Le lundi 23 février 2009 09:25:39, Adrien Futschik a écrit : > The same build instructions and the same product versions are working just > fine on RHEL 5 64bits ! > > I still believe this is a bug with OpenLDAP 2.4.14. > > Adrien I confirme that it was a problem with OpenLDAP 2.4.14, it now works fine with OpenLDAP 2.4.15. I guess this ITS is a "duplicate" of ITS#5955 Best regards, Adrien

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org 23 Feb '09

23 Feb '09

On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: > I'm still uncertain about how configure should detect the NSS header > files > though; they are not in any standardized location yet AFAICS. Like with other things, I would assume the environment to be adjusted to find the right NSS prior to running configure. -- Kurt

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 23 Feb '09

23 Feb '09

rmeggins(a)redhat.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms090802080307060909050508 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Any update on this? It looks as though there is some rearchitecture > work ongoing to make it easier to support openssl, gnutls, and moznss - > what's the status of this work? Would some additional resources be of > any assistance? Thanks for the offer. It was just a matter of timing, I wanted to make sure the new organization was stable before completing the moznss integration. Now that it looks like we've shaken out the loose ends, it won't take long to pull in the rest of the moznss support. I'm still uncertain about how configure should detect the NSS header files though; they are not in any standardized location yet AFAICS. -- -- 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#5696) Patch - support Mozilla NSS for crypto operations
by rmeggins＠redhat.com 23 Feb '09

23 Feb '09

This is a cryptographically signed message in MIME format. --------------ms090802080307060909050508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Any update on this? It looks as though there is some rearchitecture work ongoing to make it easier to support openssl, gnutls, and moznss - what's the status of this work? Would some additional resources be of any assistance? --------------ms090802080307060909050508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCzCC AuAwggJJoAMCAQICEBMdRWn5u0DKFxH7Tsz20SAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwMzE3Mjk0M1oX DTA5MTIwMzE3Mjk0M1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMoOfo+aL6KtK5e6tnKn7zhbPm6N1YxeYM5RxJ4v3/winPaNsaYrfcgSKWyy ZH8CLUoKbMndV+/BneBbIFWDNYOZEXs8Yzk0CJtaTchg3sU3yOn7qh38zyzjlSHyXFJyVEJv boTcrdGO2u0WOXj/sH5rIhdguHVcwPUu6ZrTtexqc7887R5SvFRSw3MkKeLWozHB5uQcXZO7 l6LDQU1JQbMAlteZ+fDbEXk8FUclZPg0x/fgIjs+LbPloeUK2qWCk1V85f07C135fzyemy0C MEmkAukakZFgS69Ww1LEPncBfL+5dq9pqHs18QdraT1Vgtzb0tpSPczi9H+/8fTvXwkCAwEA AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBADX7xNlAbUAG6FmqnfEpb5ieewb8OwWT1rZ0X7ZfzM9T0UIOUrN3 2kIhYAcsARWjKbedoinPUWj+a5B+gMTKSaweZ4EZV9LZmtAdvFCJSFsop1ytTeMYapgBLZpZ 02mlCGUK66r256wx645OuWP188Xe6Z34vdtjAesb9ctB27VLMIIC4DCCAkmgAwIBAgIQEx1F afm7QMoXEftOzPbRIDANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDgxMjAzMTcyOTQzWhcNMDkxMjAzMTcyOTQzWjBF MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyg5+j5ov oq0rl7q2cqfvOFs+bo3VjF5gzlHEni/f/CKc9o2xpit9yBIpbLJkfwItSgpsyd1X78Gd4Fsg VYM1g5kRezxjOTQIm1pNyGDexTfI6fuqHfzPLOOVIfJcUnJUQm9uhNyt0Y7a7RY5eP+wfmsi F2C4dVzA9S7pmtO17GpzvzztHlK8VFLDcyQp4tajMcHm5Bxdk7uXosNBTUlBswCW15n58NsR eTwVRyVk+DTH9+AiOz4ts+Wh5QrapYKTVXzl/TsLXfl/PJ6bLQIwSaQC6RqRkWBLr1bDUsQ+ dwF8v7l2r2moezXxB2tpPVWC3NvS2lI9zOL0f7/x9O9fCQIDAQABozAwLjAeBgNVHREEFzAV gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA NfvE2UBtQAboWaqd8SlvmJ57Bvw7BZPWtnRftl/Mz1PRQg5Ss3faQiFgBywBFaMpt52iKc9R aP5rkH6AxMpJrB5ngRlX0tma0B28UIlIWyinXK1N4xhqmAEtmlnTaaUIZQrrqvbnrDHrjk65 Y/Xzxd7pnfi922MB6xv1y0HbtUswggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBMd RWn5u0DKFxH7Tsz20SAwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDkwMjIzMjM0MzM0WjAjBgkqhkiG9w0BCQQxFgQUBMDGPgsl hqwc4LZEb5iv05gl45cwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQEx1Fafm7QMoXEftOzPbRIDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQEx1Fafm7QMoX EftOzPbRIDANBgkqhkiG9w0BAQEFAASCAQCqaJgb/auboz1MF7Bew2dsfNNGktv0Y54aHHiZ 3AP2XhbVP73KuRsx8n1t1vL/7L8vHuPkHSS/Q2Q/bX+VTccxFG7wUMHv4KKN93rXg2kNmNSX sQClvusTS0F5CgBtNO/08YWkaL6SERP3auh19Oik2bK7S4VUt6Q732OZ3JOoLu1J5dRApPA9 zS8m+Z5w/PdAJZ5xkYwmKqeOTEJANH3L0ECon+J4o/IlzJR2HC+3HQcTNN0IaXDRnzO5CFKy B7evjPpfxw6FwZy8OysT3dMbwe0GryKjPHOv4tSEwuX8zXVnF8LBbeKGMusIIP8YDoFXIyR1 PUeSx9IgeQU6rXVFAAAAAAAA --------------ms090802080307060909050508--

1 0

Re: (ITS#5971) Debug mode "fixes" authentication issue
by ngarratt＠gmail.com 23 Feb '09

23 Feb '09

> I'll look at the bug; in the meanwhile, you may want to fix your > configuration by adding > > chase-referrals no > > overlay chain > chain-uri <the referred URI with no DN> > chain-idassert-bind <info to allow proxyauthz of users> > # ... > > See slapo-chain for details. Another option is to use > > chase-referrals no > rebind-as-user yes > Thanks Pierangelo The fact that it worked under debug mode was throwing me off. Referrals have been fixed and it's working as expected now. Neil

1 0

Re: (ITS#5967) build failure with openssl : error: structure has no member named `ldo_tls_crlcheck'
by adrien.futschik＠atosorigin.com 23 Feb '09

23 Feb '09

Le dimanche 22 février 2009 19:36:31, Quanah Gibson-Mount a écrit : > --On Sunday, February 22, 2009 6:56 PM +0100 Adrien Futschik > > <adrien.futschik(a)atosorigin.com> wrote: > > I have just used OpenLDAP 2.4.13, with BDB 4.7.25 & OpenSSL 0.9.8j and it > > worked fine. I used the same options. > > > > > > I guess there really is a problem with Openldap 2.4.14. > > Or, your OpenSSL build is missing required features. ;) > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration There seems to be a big change between OpenLDAP 2.4.13 and OpenLDAP 2.4.14 in the way configure script chooses OpenSSL or gnutls. They used to be only on file in OpenLDAP 2.4.13 and lower handeling tls support : tls.c in librairies/libldap directory. In OpenLDAP 2.4.14 we now have : tls2.c, tls_o.c, tls_g.c and tls_m.c I guess tls_g.c should be used when specifying --with-tls=gnutls, tls_o.c should be used when specifying --with-tls=openssl tls_m.c referes to Mozilla (note sure what option trigeres this one). tls2.c is used when ? I believe that configure doesn't care about my --with-tls=openssl option. Can anyone explain to me why ? Thanks in advance, Adrien

1 0

Re: (ITS#5970) slapd
by ando＠sys-net.it 23 Feb '09

23 Feb '09

wmoreno3(a)yahoo.com wrote: > Full_Name: William Moreno > Version: openldap-server-2.4.14_1 > OS: FreeBSD 7.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (201.221.158.199) > > > Feb 22 22:09:33 micro1 slapd[841]: @(#) $OpenLDAP: slapd 2.4.14 (Feb 22 2009 > 20:44:07) $ root@micro1.domain.com.co:/usr/ports/net/openldap24-server/work/openldap-2.4.14/servers/slapd > Feb 22 22:09:33 micro1 slapd[842]: slapd starting > Feb 23 00:53:54 micro1 slapd[842]: daemon: shutdown requested and initiated. > Feb 23 00:53:54 micro1 slapd[842]: slapd shutdown: waiting for 0 > operations/tasks to finish > Feb 23 00:53:54 micro1 slapd[842]: slapd stopped. > Feb 23 01:17:16 micro1 slapd[841]: @(#) $OpenLDAP: slapd 2.4.14 (Feb 22 2009 > 20:44:07) $ root@micro1.domain.com.co:/usr/ports/net/openldap24-server/work/openldap-2.4.14/servers/slapd > Feb 23 01:17:16 micro1 slapd[842]: slapd starting > > ..... > That's into my /var/log/debug.log after system reload... > that I see is.. when started, slapd first time, it tried to start from > "/usr/ports/net/open...etc". that's OK? I don't see any indication of a bug. That string indicates where slapd was *built*, not what executable is running. This ITS will be closed. Please direct software usage questions to the openldap-software list. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs