Full_Name: Art Corcoran Version: 2.0 gamma OS: Solaris and NT URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.22.53.83) In libldap/tls.c, the method ldap_start_tls_s() has this statement: if (ldap_pvt_tls_inplace(lc->lconn_sb) != 0) return LDAP_OPERATIONS_ERROR; The error is returned if the function returns anything but zero. However, the function returns one if TLS is working OK and zero if it is not. So the bug is that if TLS is working at this point of the code, the statement will return the operations error. The statement should be as follows: if (ldap_pvt_tls_inplace(lc->lconn_sb) == 0) return LDAP_OPERATIONS_ERROR;
I do not believe this to be a bug. At 04:47 PM 8/25/00 +0000, acorcoran@vitria.com wrote: >In libldap/tls.c, the method ldap_start_tls_s() has this statement: > > if (ldap_pvt_tls_inplace(lc->lconn_sb) != 0) > return LDAP_OPERATIONS_ERROR; This says "If TLS is in place, don't attempt to start it again". >The statement should be as follows: > > if (ldap_pvt_tls_inplace(lc->lconn_sb) == 0) > return LDAP_OPERATIONS_ERROR; This says "If TLS is not in place, don't attempt to start it". This is clearly wrong. Sending the Start TLS request only makes sense if TLS is not in place (whether by previous Start TLS request or via ldaps://).
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Friday, August 25, 2000 10:18 AM > To: acorcoran@vitria.com > Cc: openldap-its@OpenLDAP.org > Subject: Re: bug in libldap/tls.c:ldap_start_tls_s() (ITS#685) > > > I do not believe this to be a bug. > > At 04:47 PM 8/25/00 +0000, acorcoran@vitria.com wrote: > >In libldap/tls.c, the method ldap_start_tls_s() has this statement: > > > > if (ldap_pvt_tls_inplace(lc->lconn_sb) != 0) > > return LDAP_OPERATIONS_ERROR; > > > This says "If TLS is in place, don't attempt to start it again". Perhaps the bug is higher up in ldapsearch. Here's what I'm seeing: 1) ldapsearch calls ldap_start_tls_s() to start TLS. 2) ldap_start_tls_s() calls ldap_open_defcon(), which sets up the connection, including TLS. 3) There is only one connection, so the loop iterates once. 4) In the first iteration of the loop, the ldap_pvt_tls_inplace() returns 1 to say TLS is inplace. 5) The if statement says "If TLS is in place, don't attempt to start it again", so it returns LDAP_OPERATIONS_ERROR. 6) ldapsearch sees return code is not LDAP_SUCCESS. With -Z, it says it couldn't start TLS; with -ZZ, aborts with EXIT_FAILURE. Here's the code from gamma ldapsearch.c: 697 if ( use_tls && ldap_start_tls_s( ld, NULL, NULL ) != LDAP_SUCCESS ) { 698 if ( use_tls > 1 ) { 699 ldap_perror( ld, "ldap_start_tls" ); 700 return EXIT_FAILURE; 701 } 702 fprintf( stderr, "WARNING: could not start TLS\n" ); 703 } open.c (gamma) or tls.c (devel): 243 int 244 ldap_start_tls_s ( LDAP *ld, 245 LDAPControl **serverctrls, 246 LDAPControl **clientctrls ) 247 { 248 #ifdef HAVE_TLS 249 LDAPConn *lc; 250 int rc; 251 char *rspoid = NULL; 252 struct berval *rspdata = NULL; 253 254 if (ld->ld_conns == NULL) { 255 rc = ldap_open_defconn( ld ); 256 if (rc != LDAP_SUCCESS) 257 return(rc); 258 } 259 260 for (lc = ld->ld_conns; lc != NULL; lc = lc->lconn_next) { 261 if (ldap_pvt_tls_inplace(lc->lconn_sb) != 0) 262 return LDAP_OPERATIONS_ERROR; 263 264 /* XXYYZ: this initiates operaton only on default connection! */ 265 rc = ldap_extended_operation_s(ld, LDAP_EXOP_START_TLS, 266 NULL, serverctrls, clientctrls, &rspoid, &rspdata); 267 268 if (rc != LDAP_SUCCESS) 269 return rc; 270 if (rspoid != NULL) 271 LDAP_FREE(rspoid); 272 if (rspdata != NULL) 273 ber_bvfree(rspdata); 274 rc = ldap_pvt_tls_start( ld, lc->lconn_sb, ld->ld_options.ldo_tls_ctx ); 275 if (rc != LDAP_SUCCESS) 276 return rc; 277 } 278 return LDAP_SUCCESS; 279 #else 280 return LDAP_NOT_SUPPORTED; 281 #endif 282 } Art
Please see devel list discussions. This is not an ldap_start_tls_s() bug. The problem is you want "ldaps://" via the command line and that functionality is missing from 2.0-gamma. It's been added to 2.x-devel (via the -H option), please test. Kurt
********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Fri, 25 Aug 2000 16:47:12 GMT from jitterbug@localhost.openldap.org [127.0.0.1] ----- The following addresses had transient non-fatal errors ----- <acorcoran@vitria.com> ----- Transcript of session follows ----- <acorcoran@vitria.com>... Deferred: Name server: vitria.com.: host name lookup failure Warning: message still undelivered after 4 hours Will keep trying until message is 4 days old
*** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to openldap-its@OpenLDAP.org. Your report has been placed into our Issue Tracking System and has been assigned the tracking number ITS#685. One of 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. You may follow the progress of this message by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=685 Please remember to retain your issue tracking number (ITS#685) on any further messages you send to us regarding this message. If you don't then you'll just waste our time and yours because we won't be able to properly track the message. In our experience many people ask questions that have been asked before. We recommend that you review our online FAQ http://www.OpenLDAP.org/faq/ and search archives of our many mailing lists (such as openldap-software and openldap-bugs). http://www.OpenLDAP.org/lists/#archives -------------- Copyright 1999 The OpenLDAP Foundation, All Rights Reserved.
changed notes changed state Open to Closed
not a bug