openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

LDAP bind using ldap_sasl_interactive_bind_s and DIGEST-MD5 fails the second time
by James Bong 01 Apr '10

01 Apr '10

I am currently using Mac OS X 10.6.2 and am attempting to use the ldap_sasl_interactive_bind_s API to do a digest-md5 authentication against Active Directory (2008, though I don't think it matters what flavor of AD is used). The bind works fine the first time. However, if I unbind and attempt to rebind as the same user, it fails with ldap_sasl_interactive_bind_s: Invalid credentials (49). If I bind with a different user, then unbind, and bind as the original user, it works. I created a simple program that illustrates the issue. When run, it binds correctly, unbinds, and then fails on the second bind: trying ldap_sasl_interactive_bind_s callback callback done ldap_sasl_interactive_bind_s Done Unbinding Unbound. ldap_sasl_interactive_bind_s callback callback done ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C0904D1, comment: AcceptSecurityContext error, data 57, v1772 Any idea why it is not possible to use the same credentials twice? Here is the test program. I tried reinitializing the sasl library with sasl_done and sasl_client_init, but that doesn't seem to make a difference. #include <ldap.h> #include <sasl/sasl.h> #include <stdio.h> typedef struct sasl_defaults { char *mech; char *realm; char *authcid; char *passwd; char *authzid; } sasl_defaults; int callback(LDAP *ld, unsigned flags, void* defaults, void *interact ) { printf("callback\n"); sasl_interact_t *in_out=(sasl_interact_t *)interact; sasl_defaults *in_defaults=(sasl_defaults *)defaults; while (in_out->id !=SASL_CB_LIST_END) { switch (in_out->id) { case SASL_CB_USER: in_out->result=in_defaults->authcid; in_out->len=strlen(in_defaults->authcid); break; case SASL_CB_AUTHNAME: in_out->result=in_defaults->authcid; in_out->len=strlen(in_defaults->authcid); break; case SASL_CB_PASS: in_out->result=in_defaults->passwd; in_out->len=strlen(in_defaults->passwd); break; case SASL_CB_GETREALM: in_out->result=""; in_out->len=strlen(""); break; } in_out++; } printf("callback done\n"); return 0; } int main (int argv, char ** argc) { printf("trying\n"); for (;;) { LDAP *ld; ldap_initialize(&ld, "ldap://dc.ad.domain.com:389"); ldap_set_option(ld,LDAP_OPT_REFERRALS,LDAP_OPT_OFF); int version=3; ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &version ); int timelimit=5; if (ldap_set_option( ld, LDAP_OPT_TIMELIMIT, (void *) &timelimit ) != LDAP_OPT_SUCCESS ) { printf("err\n"); return -1; } sasl_defaults defaults; defaults.mech = "DIGEST-MD5"; defaults.passwd="password"; defaults.authcid="user"; defaults.realm="realm.com"; defaults.authzid="user"; printf("ldap_sasl_interactive_bind_s\n"); int rc=ldap_sasl_interactive_bind_s( ld, NULL,defaults.mech, NULL, NULL, LDAP_SASL_QUIET, callback, &defaults ); if( rc != LDAP_SUCCESS ) { ldap_perror( ld, "ldap_sasl_interactive_bind_s" ); ldap_unbind(ld); return -1; } printf("ldap_sasl_interactive_bind_s Done\n"); printf("Unbinding\n"); ldap_unbind(ld); printf("Unbound.\n"); sleep(5); } }

2 1

(ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by jonathan＠phillipoux.net 01 Apr '10

01 Apr '10

Full_Name: Jonathan Clarke Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.57.67.241) This is similar to ITS #5191 (http://www.openldap.org/its/?findid=5191), except it happens with a subordinate LDAP database. Consider this configuration : 8<--------------------------------------- database ldap suffix "o=test,o=sub" uri "ldap://localhost:1234" subordinate idassert-bind mode=none bindmethod=simple flags=prescriptive timeout=0 network-timeout=0 binddn="cn=svc,o=test" credentials="verysecret" idassert-authzFrom dn.regex:.* single-conn yes overlay rwm rwm-suffixmassage "o=test,o=sub" "o=test" database null suffix "o=sub" rootdn "cn=Manager,o=sub" rootpw secret overlay glue 8<--------------------------------------- A search with pagedResults control returns results as expected, but with a response control containing some garbage: result: 0 Success control:: qOEpCDg0MC4xMTM1NTYuMS40LjMxOSBmYWxzZSBNSVFBQUFBSkFnRUFCQVFFQUFBQQ== Some gdb'ing shows that backglue copies over the pointers to rs->sr_ctrls into glue_state->ctrls. But then, back-ldap's ldap_back_search does a ldap_controls_free() on rs->sr_ctrls. And so, the returned control contains garbage (mostly). I haven't been able to come up with a patch yet, just commenting line 454 of back-ldap/search.c works. Running out of time for now...

1 0

RE: (ITS#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started
by bcolston＠xtec.com 01 Apr '10

01 Apr '10

Provider slapd configuration (partial): serverID 000 database bdb suffix "dc=authentx" rootdn "SUPPRESSED" rootpw SUPPRESSED directory /authentx/db/ldap/authentx-sync1 overlay syncprov syncprov-checkpoint 100 15 syncprov-sessionlog 5000 checkpoint 128 20 index objectClass eq,pres index entryCSN,entryUUID eq cachesize 100000 dncachesize 200000 idlcachesize 1000 sizelimit 500000 timelimit 36000 Consumer slapd configuration (partial): serverID 001 database bdb suffix "dc=authentx" rootdn "SUPPRESSED" rootpw SUPPRESSED directory /authentx/db/ldap/authentx-sync2 syncrepl rid=001 provider=ldap://localhost:3891 type=refreshAndPersist retry="300 60 60 +" searchbase="dc=authentx" scope=sub schemachecking=off bindmethod=simple binddn="SUPPRESSED" credentials="SUPPRESSED" checkpoint 128 20 index objectClass eq,pres index entryCSN,entryUUID eq cachesize 100000 dncachesize 200000 idlcachesize 1000 sizelimit 500000 timelimit 36000 Barry -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Wednesday, March 31, 2010 9:17 PM To: bcolston(a)xtec.com Cc: openldap-its(a)openldap.org Subject: Re: (ITS#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started bcolston(a)xtec.com wrote: > Full_Name: Barry Colston > Version: 2.4.21 > OS: Fedora 12 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.255.208.210) > > > When a consumer slapd is started, if the provider slapd has had only Add > operations performed while the consumer slapd was down, the provider slapd sends > the consumer slapd the entryUUIDs of all records in the provider database. > Note: this is not a list of all records that have been added/changed/deleted > since the previous synchronization based on the consumer's contextCSN, it is a > list of all records in the LDAP database (for some of our customers, this is > 10,000,000 entryUUIDs that are returned to the consumer slapd.) That is the normal behavior of syncrepl. Read the Admin Guide and/or RFC4533. > The scenario to reproduce this problem is: > 1. Start provider slapd > 2. Start consumer slapd > 3. Ensure that provider contextCSN matches consumer contextCSN > 4. Shutdown consumer slapd > 5. Add records to provider slapd (1 record is sufficient to create the problem) > 6. Start consumer slapd with debug turned on (so the messages being sent can be > viewed). The consumer slapd receives 1 to N LDAP_RES_INTERMEDIATE SYNC_ID_SETs > (message type = 121) containing the entryUUIDs of the records in the provider's > database, followed by a LDAP_RES_SEARCH_ENTRY, LDAP_SYNC_ADD (message type = > 100) message for each record added to the provider, then finally a > LDAP_RES_INTERMEDIATE, REFRESH_PRESENT message (message type = 121) message > containing the provider's sync cookie. > > I am running OpenLDAP 2.4.21 with Berkeley 4.6.21 (with all patches) on Fedora > 12. Running sync replication in RefreshAndPersist mode. > > Note: if at least 1 Modify or Delete operation is performed against the provider > slapd while the consumer slapd is down, when the consumer slapd is started, the > provider slapd does NOT send the Sync ID sets containing the entryUUIDs of all > records in the provider database. Using the syncprov_sessionlog can allow the provider to shortcut this. Since you haven't show any details of your configuration, we can't say if this difference in behavior is a bug or a config error. -- -- 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#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started
by hyc＠symas.com 01 Apr '10

01 Apr '10

bcolston(a)xtec.com wrote: > Full_Name: Barry Colston > Version: 2.4.21 > OS: Fedora 12 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.255.208.210) > > > When a consumer slapd is started, if the provider slapd has had only Add > operations performed while the consumer slapd was down, the provider slapd sends > the consumer slapd the entryUUIDs of all records in the provider database. > Note: this is not a list of all records that have been added/changed/deleted > since the previous synchronization based on the consumer's contextCSN, it is a > list of all records in the LDAP database (for some of our customers, this is > 10,000,000 entryUUIDs that are returned to the consumer slapd.) That is the normal behavior of syncrepl. Read the Admin Guide and/or RFC4533. > The scenario to reproduce this problem is: > 1. Start provider slapd > 2. Start consumer slapd > 3. Ensure that provider contextCSN matches consumer contextCSN > 4. Shutdown consumer slapd > 5. Add records to provider slapd (1 record is sufficient to create the problem) > 6. Start consumer slapd with debug turned on (so the messages being sent can be > viewed). The consumer slapd receives 1 to N LDAP_RES_INTERMEDIATE SYNC_ID_SETs > (message type = 121) containing the entryUUIDs of the records in the provider's > database, followed by a LDAP_RES_SEARCH_ENTRY, LDAP_SYNC_ADD (message type = > 100) message for each record added to the provider, then finally a > LDAP_RES_INTERMEDIATE, REFRESH_PRESENT message (message type = 121) message > containing the provider's sync cookie. > > I am running OpenLDAP 2.4.21 with Berkeley 4.6.21 (with all patches) on Fedora > 12. Running sync replication in RefreshAndPersist mode. > > Note: if at least 1 Modify or Delete operation is performed against the provider > slapd while the consumer slapd is down, when the consumer slapd is started, the > provider slapd does NOT send the Sync ID sets containing the entryUUIDs of all > records in the provider database. Using the syncprov_sessionlog can allow the provider to shortcut this. Since you haven't show any details of your configuration, we can't say if this difference in behavior is a bug or a config error. -- -- 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#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started
by bcolston＠xtec.com 31 Mar '10

31 Mar '10

Full_Name: Barry Colston Version: 2.4.21 OS: Fedora 12 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.255.208.210) When a consumer slapd is started, if the provider slapd has had only Add operations performed while the consumer slapd was down, the provider slapd sends the consumer slapd the entryUUIDs of all records in the provider database. Note: this is not a list of all records that have been added/changed/deleted since the previous synchronization based on the consumer's contextCSN, it is a list of all records in the LDAP database (for some of our customers, this is 10,000,000 entryUUIDs that are returned to the consumer slapd.) The scenario to reproduce this problem is: 1. Start provider slapd 2. Start consumer slapd 3. Ensure that provider contextCSN matches consumer contextCSN 4. Shutdown consumer slapd 5. Add records to provider slapd (1 record is sufficient to create the problem) 6. Start consumer slapd with debug turned on (so the messages being sent can be viewed). The consumer slapd receives 1 to N LDAP_RES_INTERMEDIATE SYNC_ID_SETs (message type = 121) containing the entryUUIDs of the records in the provider's database, followed by a LDAP_RES_SEARCH_ENTRY, LDAP_SYNC_ADD (message type = 100) message for each record added to the provider, then finally a LDAP_RES_INTERMEDIATE, REFRESH_PRESENT message (message type = 121) message containing the provider's sync cookie. I am running OpenLDAP 2.4.21 with Berkeley 4.6.21 (with all patches) on Fedora 12. Running sync replication in RefreshAndPersist mode. Note: if at least 1 Modify or Delete operation is performed against the provider slapd while the consumer slapd is down, when the consumer slapd is started, the provider slapd does NOT send the Sync ID sets containing the entryUUIDs of all records in the provider database.

1 0

Re: (ITS#6488) Nssov updates for new versions of nss-pam-ldapd
by crispy＠cluenet.org 31 Mar '10

31 Mar '10

Hi, any word on if this can be incorporated? Thanks. On Sun, 2010-03-07 at 01:24 +0000, 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#6488. > > 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#6488) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6488) > > 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=6488 > > Please remember to retain your issue tracking number (ITS#6488) > 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. >

1 0

Re: (ITS#6501) DBTzeros in bdb/hdb
by hyc＠symas.com 31 Mar '10

31 Mar '10

mbackes(a)symas.com wrote: > Full_Name: Matthew Backes > Version: 2.4, HEAD > OS: any > URL: > Submission from: (NULL) (76.88.107.46) > > > The lockobj's in BDB aren't being DBTzero()'d fully before use; they > consist of more than just .data and .size, so this leaves uninit > memory that gets branched on. > > Needs to be applied to HEAD and 2.4. (2.3 as well, for those still > tracking that for some reason, probably all branches with BDB/HDB) Thanks, fixed in HEAD. The dn2id.c patch is obsolete, that function is no longer used. > > Patch vs HEAD: > > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/cache.c,v > retrieving revision 1.214 > diff -u -u -r1.214 cache.c > --- cache.c 4 Nov 2009 05:09:51 -0000 1.214 > +++ cache.c 29 Mar 2010 16:41:59 -0000 > @@ -184,6 +184,7 @@ > > if ( !lock ) return 0; > > + DBTzero(&lockobj ); > lockobj.data =&ei->bei_id; > lockobj.size = sizeof(ei->bei_id) + 1; > > @@ -225,6 +226,7 @@ > else > db_rw = DB_LOCK_READ; > > + DBTzero(&lockobj ); > lockobj.data =&ei->bei_id; > lockobj.size = sizeof(ei->bei_id) + 1; > > Index: dn2id.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/dn2id.c,v > retrieving revision 1.169 > diff -u -u -r1.169 dn2id.c > --- dn2id.c 15 Feb 2010 14:25:47 -0000 1.169 > +++ dn2id.c 29 Mar 2010 16:41:59 -0000 > @@ -42,6 +42,7 @@ > else > db_rw = DB_LOCK_READ; > > + DBTzero(&lockobj ); > lockobj.data = dn->bv_val; > lockobj.size = dn->bv_len; > > -- -- 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#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by masarati＠aero.polimi.it 30 Mar '10

30 Mar '10

> On Tue, 2010-03-02 at 15:30 +1100, Andrew Bartlett wrote: >> On Mon, 2009-08-03 at 20:44 +0200, masarati(a)aero.polimi.it wrote: >> > [Resending because I forgot the ITS number in the subject] >> > >> > I have a simple prototype that on add/modrdn populates/maintains an >> > attribute (rdnValue) with the distinguished values of the naming >> > attributes of the RDN. While doing this, it also checks for >> uniqueness of >> > the rdnValue value within siblings. >> > >> > You can find it here >> > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.c> >> > >> > Please test and comment. I hope it does what intended. >> >> I'm starting to look at this now. I'm sorry so many months have past >> since you posted it. > > I've now added it into Samba's provision, and using the diff I attach, > against current 'master', I get the attached error. > > It seems to be unable to add the base DN. (The very first entry in the > database). Try this: <www.aero.polimi.it/masarati/Download/pierangelo-masarati-2010-03-30-rdnval.…>. In fact, when adding the suffix entry, the overlay was erroneously checking its siblings from its superior, which is very likely to fail. p.

1 0

Re: (ITS#6500) get_ldap_property returns stale data from time to time
by alinachegalati＠yahoo.com 30 Mar '10

30 Mar '10

--0-808694875-1269950414=:35747 Content-Type: text/plain; charset=us-ascii i was using the deprecated function from openldap. i switched to ldap_value_free_len, i'll run more tests to see if i still have the problem. ________________________________ From: "masarati(a)aero.polimi.it" <masarati(a)aero.polimi.it> To: alinachegalati(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Tue, March 30, 2010 7:15:51 AM Subject: Re: (ITS#6500) get_ldap_property returns stale data from time to time Not clear why you think this is an OpenLDAP bug. There's too little information to determine whether your application is using OpenLDAP's client library correctly. p. > Full_Name: Alin Vasile > Version: 2.4.19 > OS: SuSE 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.17) > > > Hi, > > In a high load apache environment I am performing some ldap searches for > some > requests using a custom developed application and the OpenLdap client > libraries. >>From time to time I have the following segmentation fault: > > Program terminated with signal 11, Segmentation fault. > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > 30 if ( v != NULL && v[0] != NULL ) { > (gdb) backtrace > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > #1 0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, > ldap_request=0x76ff60) at ldap_query.c:353 > > And the function is : > > char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, > apr_pool_t* context) { > > char ** v = ldap_get_values(ldap, entry, attribute); > > if ( v != NULL && v[0] != NULL ) { > char* ret = apr_pstrdup(context, v[0] ); > ldap_value_free( v ); > return ret; > } > > return NULL; > > } > > Note that most of the queries (99%) work fine. > > Did anyone experienced something simmilar? > > Thanks, > Alin > --0-808694875-1269950414=:35747 Content-Type: text/html; charset=us-ascii <html><head><style type="text/css"></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div> </div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">i was using the deprecated function from openldap. i switched to ldap_value_free_len, i'll run more tests to see if  i still have the problem. <div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><hr size="1">From: "masarati(a)aero.polimi.it" <masarati(a)aero.polimi.it> To: alinachegalati(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Tue, March 30, 2010 7:15:51 AM Subject: Re: (ITS#6500) get_ldap_property returns stale data from time to time Not clear why you think this is an OpenLDAP bug.  There's too little information to determine whether your application is using OpenLDAP's client library correctly. p. > Full_Name: Alin Vasile > Version: 2.4.19 > OS: SuSE 11 > URL: <a href="ftp://ftp.openldap.org/incoming/" target="_blank">ftp://ftp.openldap.org/incoming/</a> > Submission from: (NULL) (194.237.142.17) > > > Hi, > >  In a high load apache environment I am performing some ldap searches for > some > requests using a custom developed application and the OpenLdap client > libraries. >>From time to time I have the following segmentation fault: > > Program terminated with signal 11, Segmentation fault. > #0  0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) >    at ldap_query.c:30 > 30          if ( v != NULL && v[0] != NULL ) { > (gdb) backtrace > #0  0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) >    at ldap_query.c:30 > #1  0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, > ldap_request=0x76ff60) at ldap_query.c:353 > > And the function is : > > char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, > apr_pool_t* context) { > >    char ** v = ldap_get_values(ldap, entry, attribute); > >    if ( v != NULL && v[0] != NULL ) { >        char* ret = apr_pstrdup(context,  v[0] ); >        ldap_value_free( v ); >        return ret; >    } > >    return NULL; > > } > > Note that most of the queries (99%) work fine. > > Did anyone experienced something simmilar? > > Thanks, > Alin > </div></div> </div> </body></html> --0-808694875-1269950414=:35747--

1 0

Re: (ITS#6502) Build failure tls_g.c
by hyc＠symas.com 30 Mar '10

30 Mar '10

This is a dup of ITS#5930 (and probably a few others). Solaris ships with a prehistoric version of GnuTLS (even before they added version stamps to the gnutls.h header file). You cannot use it. Use OpenSSL or install a recent version of GnuTLS instead. kenneth.greiner(a)paetec.com wrote: > Full_Name: Ken Greiner > Version: 2.4.21 > OS: SunOS 5.10 Generic_141445-09 i86pc i386 i86pc > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.80.108.55) > > > ./configure --disable-slapd --prefix=$HOME > OK > ./make depend > OK > ./make > ... lots of good stuff.. then -> > > /bin/sh ../../libtool --mode=compile gcc -g -O2 -I../../include > -I../../include -DLDAP_LIBRARY -c tls_g.c > gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c -fPIC > -DPIC -o .libs/tls_g.o > tls_g.c:73: error: syntax error before "gnutls_kx_algorithm_t" > tls_g.c:73: warning: no semicolon at end of struct or union > tls_g.c:74: warning: data definition has no type or storage class > tls_g.c:75: error: syntax error before "mac" > tls_g.c:75: warning: data definition has no type or storage class > .. and so on. > oops! Failed on this tls_g.c file. > > -- -- 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

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