- openldap-bugs - openldap.org

(ITS#5105) 64 bit Windows portability errors in liblber
by alexey.melnikov＠isode.com 24 Aug '07

24 Aug '07

Full_Name: Alexey Melnikov Version: 2.3.28 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/alexey-melnikov-070824.diff Submission from: (NULL) (62.3.217.250) Visual C 8.0 reports warnings when building liblber with /Wp64 (64 bit Windows portability warnings). The warnings are actually bugs on Windows 64: bprint.c(269) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'long' bprint.c(270) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'long' bprint.c(271) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'long' bprint.c(308) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'long' bprint.c(309) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'long' decode.c(376) : warning C4311: 'type cast' : pointer truncation from 'BerVarray' to 'long' decode.c(377) : warning C4312: 'type cast' : conversion from 'unsigned long' to 'berval *' of greater size decode.c(409) : warning C4311: 'type cast' : pointer truncation from 'BerVarray' to 'long' decode.c(409) : warning C4312: 'type cast' : conversion from 'unsigned long' to 'BerVarray' of greater size Warnings in bprint.c are caused by use of %X which is incorrect on Windows 64. Portable %p should be used instead. Problems in decode.c are caused by typecasting a pointer to a long. Unfortunately on Windows 64 a pointer is 64 bits, while "long" is still 32bits, which is obviously problematic. The fix is to use typecase to "char *" instead, as pointer arithmetics will work for it. I've uploaded the patch as <ftp://ftp.openldap.org/incoming/alexey-melnikov-070824.diff>

1 0

Re: (ITS#5096) [enhancement] back-sql should provide a means to reload schema mapping runtime
by ando＠sys-net.it 24 Aug '07

24 Aug '07

ando(a)sys-net.it wrote: > This is a request enhancement for a means to reload schema mapping run-time, > without the need to stop slapd. The ideal candidate for this feature seems to > be back-monitor. ... of course, adding back-config support would probably allow to remove and add the database again, resulting in the expected behavior. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by hyc＠symas.com 23 Aug '07

23 Aug '07

Donn Cave wrote: > It looks easy enough to me to code up an order independent version that > will actually work. I would initialize adds[] and dels[] with old & new > berval pointers, iterate through dels[] and adds[] (nested), and clear > both on match. The code is easier to follow and empirically I see one > fewer matches in the cases I tested it on. But that's just a test of > the algorithm - I haven't sorted out what needs to be done at the end of > the function where mcur etc. are modified depending on i == j. The only way to do this right, without dying on an O(n^2) algorithm, is to sort both arrays first and then walk through them in order as the original code did. If you want to submit such a patch, please do. I don't have a lot of time to focus on this at the moment. -- -- Howard Chu Chief Architect, 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#5104) OpenLDAP build breaks with SSL
by ando＠sys-net.it 23 Aug '07

23 Aug '07

Hallvard B Furuseth wrote: > ando(a)sys-net.it writes: >> Actually, things seem to work just fine. I erroneously built >> openssl-0.9.8e without shared, and in that case it doesn't work. > > What's wrong with building it without shared? The build instructions > doesn't say we need the shared variant. I screwed things up, because I was building on Opteron, and ld complained about some non-relocatable symbols in libssl.a. Probably it either didn't guess well at my system, or I missed something. So it was probably me. Explicitly adding LIBS=-ldl fixed configure, but not the build later on. But I think this is off-topic with respect to this ITS. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5104) OpenLDAP build breaks with SSL
by h.b.furuseth＠usit.uio.no 23 Aug '07

23 Aug '07

ando(a)sys-net.it writes: > Actually, things seem to work just fine. I erroneously built > openssl-0.9.8e without shared, and in that case it doesn't work. What's wrong with building it without shared? The build instructions doesn't say we need the shared variant. -- Hallvard

1 0

Re: (ITS#5104) OpenLDAP build breaks with SSL
by ando＠sys-net.it 23 Aug '07

23 Aug '07

PLEASE KEEP REPLIES IN COPY ON THE ITS! Richard Beckett wrote: > I built openssl with the shared option for the config script. I have the > LD_LIBRARY_PATH set to /usr/local/lib which is where I put the Berkeley > DB libraries. Do I need something else? > > Here is what I get from the"make" after having run "make depend": > > ./.libs/libldap.a(tls.o)(.text+0x593): In function `sb_tls_bio_read': > /usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/tls.c:676: > undefined reference to `BIO_clear_flags' Those symbols (at least in openssl-9.8.0e) are defined in libcrypto. You don't show the linker command line that is failing, but I still believe your build environment is broken, since OpenLDAP explicitly links libcrypto along with libssl. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5104) OpenLDAP build breaks with SSL
by ando＠sys-net.it 23 Aug '07

23 Aug '07

Please keep replies on the list Richard Beckett wrote: > Pierangelo, thank you very much for the reply. Can you suggest a > work-around for the time being? Do I need to edit the Makefile? I have > not worked at this level for many years and my knowledge of "make" is > rusty. Actually, things seem to work just fine. I erroneously built openssl-0.9.8e without shared, and in that case it doesn't work. I suspect your build environment is broken (possibly the way you built openssl?). Please check if it's built correctly; if it is, please inspect the config.log resulting from building OpenLDAP to get some hint about the reason of the failure. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5104) OpenLDAP build breaks with SSL
by ando＠sys-net.it 23 Aug '07

23 Aug '07

rbeckett(a)exelixis.com wrote: > Full_Name: Richard Beckett > Version: openldap-2.3.38 > OS: Solaris 10/RHEL v4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (65.209.203.254) > > > After compiling openssl-0.9.8e and installing it, then configuring > openldap-2.3.38 with ./configure followed by make depends and make, the make > fails. If I remove the /usr/local/lib/*ssl* and /usr/local/include/ssl* > directories and files then the make works fine. This occurs on both the Linux > and Solaris hosts It seems that linking a program with openssl needs to explicitly provide -ldl in LIBS. I'm investigating whether this is related to OpenLDAP's configure or related to libssl's build/installation. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5104) OpenLDAP build breaks with SSL
by rbeckett＠exelixis.com 23 Aug '07

23 Aug '07

Full_Name: Richard Beckett Version: openldap-2.3.38 OS: Solaris 10/RHEL v4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.209.203.254) After compiling openssl-0.9.8e and installing it, then configuring openldap-2.3.38 with ./configure followed by make depends and make, the make fails. If I remove the /usr/local/lib/*ssl* and /usr/local/include/ssl* directories and files then the make works fine. This occurs on both the Linux and Solaris hosts

1 0

(ITS#5103) ldap_create_passwordpolicy_control creates illegal pp request control
by kurt＠OpenLDAP.org 22 Aug '07

22 Aug '07

Full_Name: Kurt Zeilenga Version: HEAD OS: Mac OS X 10.4.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.180.46.200) Submitted by: kurt Fixed in HEAD libraries/libldap/ppolicy.c 1.14,1.15 libraries/libldap/controls.c 1.53,1.55

3 4

Re: (ITS#5102) back-perl build issues
by ando＠sys-net.it 22 Aug '07

22 Aug '07

kurt(a)OpenLDAP.org wrote: > With perl v5.8.8 from macports (recently upgraded) Works fine here (Linux) > Entering directory `/Users/kurt/Work/devel/servers/slapd/back-perl' > /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -g -O2 > -I../../../include -I../../../include -I.. -I./.. -I/opt/local/include > -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe > -Wdeclaration-after-statement -I/opt/local/include > -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include > -I/usr/pkg/include/db45 -c init.c > cc -g -O2 -I../../../include -I../../../include -I.. -I./.. > -I/opt/local/include -fno-common -DPERL_DARWIN -no-cpp-precomp > -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/local/include > -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include > -I/usr/pkg/include/db45 -c init.c -o init.o > init.c:90: error: parse error before 'ConfigReply' > init.c: In function 'perl_back_db_init': > init.c:92: error: number of arguments doesn't match prototype > proto-perl.h:27: error: prototype declaration This was recently (sort of: 2 weeks ago) changed. Are you sure you updated? 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Saturn v1.1 on openldap v2.4.4alpha
by Domagoj Babic 22 Aug '07

22 Aug '07

Hi, I'd appreciate if anyone could provide feedback on this report from another tool. I've filtered out all the warnings that are provably false. BTW, playing with openldap for a couple of days, I found that the code is of much lower quality than some other open source projects, like ISC bind & ntp, openssh,... Static checkers also find more bugs. Some things I spotted: - code is very non-uniform, the same things are done in very different ways - in several places (10-20) pointers are checked with an assertion, but after the pointer has already been dereferenced. What's the purpose of assertions then? - "fat interfaces" - very long sequences of dereferences, like: *desc->ad_type->sat_equality->smr_normalize make GDB debugging harder, discourage consistency checking, and make static checking reports less readable. - inconsistency, a lot of it, for instance, a pointer is dereferenced, and ten lines below it's actually checked for NULL and then dereferenced Anyways, here is the report, I hope it's going to be helpful: Please replace ??? with Yes/No, and a short explanation. Bad programming practices are not considered bugs. A bug (by my definition) is a sequence of events that would crash the app, no matter how small the probability is, or how irrelevant the app is. Please, also consider the calling context (unlike Calysto, Saturn does not provide a complete trace, so it is hard to figure out whether the functions can be called under the right conditions to trigger the bug). If you can prove that the function can never be called so as to trigger the 'bug', then it's not a bug. ---------------------------------------------------------------- Bug: ??? @blue @2114 blue __arg0*.bv_val of function select_backend can evaluate to NULL select_backend (2114:servers/slapd/acl.c), final site of dereference is: (678:servers/slapd/backend.c) @servers/slapd/acl.c @Null pointer is passed to a function which dereferences it. ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @violet @774 violet (INCONSISTENT USE) Possible null dereference __arg1*.e_nname.bv_val. This variable is checked for Null at lines: 704, and is dereferenced through call chain: servers/slapd/acl.c:regex_matches (774:servers/slapd/acl.c), acl_string_expand (2507:servers/slapd/acl.c), final site of dereference is: (2455:servers/slapd/acl.c) @servers/slapd/acl.c @Interprocedural inconsistency error @violet @837 violet (INCONSISTENT USE) Possible null dereference __arg1*.e_nname.bv_val. This variable is checked for Null at lines: 704, and is dereferenced through call chain: acl_string_expand (837:servers/slapd/acl.c), final site of dereference is: (2455:servers/slapd/acl.c) @servers/slapd/acl.c @Interprocedural inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like a bug. @violet @3868 violet (INCONSISTENT USE) Possible null dereference __arg0*.si_anlist. This variable is checked for Null at lines: 3859, and is dereferenced through call chain: anlist_unparse (3868:servers/slapd/syncrepl.c), final site of dereference is: (2841:servers/slapd/bconfig.c) @servers/slapd/syncrepl.c @Interprocedural inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like a bug. @red @1753 red Possible NULL dereference of keys+keycount @servers/slapd/schema_init.c @Intraprocedural Null error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @orange @2212 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_suffix+i. This variable is checked for Null at lines: 2192 @servers/slapd/bconfig.c @Inconsistency error @orange @2211 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_suffix+i. This variable is checked for Null at lines: 2192 @servers/slapd/bconfig.c @Inconsistency error @orange @2212 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_suffix+(i+1). This variable is checked for Null at lines: 2192 @servers/slapd/bconfig.c @Inconsistency error @orange @2209 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_suffix+i. This variable is checked for Null at lines: 2192 @servers/slapd/bconfig.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @orange @3147 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_update_refs+i. This variable is checked for Null at lines: 3135 @servers/slapd/bconfig.c @Inconsistency error @orange @3149 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_update_refs+(i+1). This variable is checked for Null at lines: 3135 @servers/slapd/bconfig.c @Inconsistency error @orange @3148 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_update_refs+i. This variable is checked for Null at lines: 3135 @servers/slapd/bconfig.c @Inconsistency error @orange @3149 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_update_refs+i. This variable is checked for Null at lines: 3135 @servers/slapd/bconfig.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? There seems to be some correlation between default_passwd_hash and c->valx interprocedurally, but I couldn't figure it out. @orange @1934 orange (INCONSISTENT USE) Possible null dereference of variable default_passwd_hash+i. This variable is checked for Null at lines: 1938 @servers/slapd/bconfig.c @Inconsistency error @orange @1933 orange (INCONSISTENT USE) Possible null dereference of variable default_passwd_hash+i. This variable is checked for Null at lines: 1938 @servers/slapd/bconfig.c @Inconsistency error @orange @1934 orange (INCONSISTENT USE) Possible null dereference of variable default_passwd_hash+(i+1). This variable is checked for Null at lines: 1938 @servers/slapd/bconfig.c @Inconsistency error @orange @1932 orange (INCONSISTENT USE) Possible null dereference of variable default_passwd_hash+i. This variable is checked for Null at lines: 1938 @servers/slapd/bconfig.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? The same as above @orange @2743 orange (INCONSISTENT USE) Possible null dereference of variable default_referral+i. This variable is checked for Null at lines: 2731 @servers/slapd/bconfig.c @Inconsistency error @orange @2744 orange (INCONSISTENT USE) Possible null dereference of variable default_referral+i. This variable is checked for Null at lines: 2731 @servers/slapd/bconfig.c @Inconsistency error @orange @2745 orange (INCONSISTENT USE) Possible null dereference of variable default_referral+i. This variable is checked for Null at lines: 2731 @servers/slapd/bconfig.c @Inconsistency error @orange @2745 orange (INCONSISTENT USE) Possible null dereference of variable default_referral+(i+1). This variable is checked for Null at lines: 2731 @servers/slapd/bconfig.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @orange @377 orange (INCONSISTENT USE) Possible null dereference of variable b1. This variable is checked for Null at lines: 348 @servers/slapd/backglue.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like a false positive, but not sure. @violet @463 violet (INCONSISTENT USE) Possible null dereference servers/slapd/oc.c:oc_list.stqh_first*.soc_next.stqe_next. This variable is checked for Null at lines: 461, and is dereferenced through call chain: servers/slapd/oc.c:oc_delete_names (463:servers/slapd/oc.c), final site of dereference is: (394:servers/slapd/oc.c) @servers/slapd/oc.c @Interprocedural inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @orange @2807 orange (INCONSISTENT USE) Possible null dereference of variable a->acl_attrs+0. This variable is checked for Null at lines: 2784 @servers/slapd/aclparse.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like attrs_alloc can return NULL @799. @red @869 red Possible NULL dereference of a with trace a @servers/slapd/entry.c @Intraprocedural error with loop summary propagation @red @837 red Possible NULL dereference of a with trace a @servers/slapd/entry.c @Intraprocedural error with loop summary propagation @red @871 red Possible NULL dereference of a with trace a @servers/slapd/entry.c @Intraprocedural error with loop summary propagation @red @856 red Possible NULL dereference of a with trace a @servers/slapd/entry.c @Intraprocedural error with loop summary propagation @red @840 red Possible NULL dereference of a with trace a @servers/slapd/entry.c @Intraprocedural error with loop summary propagation @red @838 red Possible NULL dereference of a with trace a @servers/slapd/entry.c @Intraprocedural error with loop summary propagation ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like out is initialized in the loop body, and the loop is executed at least once, but I'm not sure. @orange @292 orange (INCONSISTENT USE) Possible null dereference of variable out+outpos. This variable is checked for Null at lines: 268 @libraries/liblunicode/ucstr.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Bug, pointer returned by realloc not checked. @red @288 red Possible NULL dereference of values+(nvalues+j) with trace values @tests/progs/slapd-search.c @Intraprocedural error with loop summary propagation ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like anew->an_name.bv_val can remain uninitialized or NULL @red @943 red Possible NULL dereference of anew->an_name.bv_val+0 with trace anew*.an_name.bv_val @servers/slapd/ad.c @Intraprocedural error with loop summary propagation @red @921 red Possible NULL dereference of anew->an_name.bv_val+0 with trace anew*.an_name.bv_val @servers/slapd/ad.c @Intraprocedural error with loop summary propagation ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Inconsistency, can it be NULL? @orange @128 orange (INCONSISTENT USE) Possible null dereference of variable info. This variable is checked for Null at lines: 136 @libraries/librewrite/rule.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @blue @172 blue Trace entry of function tests/progs/slapd-modrdn.c:do_modrdn evaluates to NULL and is dereferenced through call chain: tests/progs/slapd-modrdn.c:do_modrdn (172:tests/progs/slapd-modrdn.c), final site of dereference is: (205:tests/progs/slapd-modrdn.c) @tests/progs/slapd-modrdn.c @Interprocedural Null error with loop summary propagation ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like bugs - SF_POP can return NULL. @blue @385 blue __arg1 of function slap_set_join can evaluate to NULL slap_set_join (385:servers/slapd/sets.c), final site of dereference is: (230:servers/slapd/sets.c) @servers/slapd/sets.c @Null pointer is passed to a function which dereferences it. @blue @411 blue __arg1 of function slap_set_join can evaluate to NULL slap_set_join (411:servers/slapd/sets.c), final site of dereference is: (230:servers/slapd/sets.c) @servers/slapd/sets.c @Null pointer is passed to a function which dereferences it. ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like bugs. @orange @231 orange (INCONSISTENT USE) Possible null dereference of variable rset+j. This variable is checked for Null at lines: 134, 188 @servers/slapd/sets.c @Inconsistency error @orange @244 orange (INCONSISTENT USE) Possible null dereference of variable rset+j. This variable is checked for Null at lines: 134, 188 @servers/slapd/sets.c @Inconsistency error @orange @235 orange (INCONSISTENT USE) Possible null dereference of variable rset+j. This variable is checked for Null at lines: 134, 188 @servers/slapd/sets.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like bugs. @orange @243 orange (INCONSISTENT USE) Possible null dereference of variable lset+i. This variable is checked for Null at lines: 120, 188 @servers/slapd/sets.c @Inconsistency error @orange @235 orange (INCONSISTENT USE) Possible null dereference of variable lset+i. This variable is checked for Null at lines: 120, 188 @servers/slapd/sets.c @Inconsistency error @orange @230 orange (INCONSISTENT USE) Possible null dereference of variable lset+i. This variable is checked for Null at lines: 120, 188 @servers/slapd/sets.c @Inconsistency error @orange @244 orange (INCONSISTENT USE) Possible null dereference of variable lset+i. This variable is checked for Null at lines: 120, 188 @servers/slapd/sets.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? This pointer is checked @210, and if it's NULL a proper msg is printed, and then the pointer can be dereferenced. Would this be considered a bug, or a normal sequence of events? @blue @227 blue __arg0 of function servers/slurpd/ldap_op.c:free_ldmarr can evaluate to NULL servers/slurpd/ldap_op.c:free_ldmarr (227:servers/slurpd/ldap_op.c), final site of dereference is: (574:servers/slurpd/ldap_op.c) @servers/slurpd/ldap_op.c @Null pointer is passed to a function which dereferences it. ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Looks like a bug. @red @349 red Possible NULL dereference of ldmarr+nops @servers/slurpd/ldap_op.c @Intraprocedural Null error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @red @646 red Possible NULL dereference of srs with trace srs @servers/slapd/overlays/syncprov.c @Intraprocedural error with loop summary propagation @red @649 red Possible NULL dereference of srs with trace srs @servers/slapd/overlays/syncprov.c @Intraprocedural error with loop summary propagation @red @647 red Possible NULL dereference of srs with trace srs @servers/slapd/overlays/syncprov.c @Intraprocedural error with loop summary propagation ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Can that pointer be NULL? @orange @545 orange (INCONSISTENT USE) Possible null dereference of variable op->o_bd. This variable is checked for Null at lines: 551, 553, 597 @servers/slapd/backover.c @Inconsistency error @orange @477 orange (INCONSISTENT USE) Possible null dereference of variable op->o_bd. This variable is checked for Null at lines: 483, 485, 529 @servers/slapd/backover.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Looks like a bug if the loop body @1104 is not executed. @red @1112 red Possible NULL dereference of on with trace on @servers/slapd/backover.c @Intraprocedural error with loop summary propagation @red @1113 red Possible NULL dereference of on with trace on @servers/slapd/backover.c @Intraprocedural error with loop summary propagation ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Bad programming practice, what's the point of checking the pointer after dereference?? Is this a bug? @orange @528 orange (INCONSISTENT USE) Possible null dereference of variable val. This variable is checked for Null at lines: 534 @servers/slapd/value.c @Inconsistency error @orange @465 orange (INCONSISTENT USE) Possible null dereference of variable val. This variable is checked for Null at lines: 471 @servers/slapd/value.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Bad programming practice, is it a bug? @orange @298 orange (INCONSISTENT USE) Possible null dereference of variable data. This variable is checked for Null at lines: 302 @libraries/librewrite/ldapmap.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like a bug. @orange @194 orange (INCONSISTENT USE) Possible null dereference of variable defaults. This variable is checked for Null at lines: 115, 118, 121, 125 @libraries/liblutil/sasl.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @red @147 red Possible NULL dereference of p @libraries/liblutil/avl.c @Intraprocedural Null error @red @148 red Possible NULL dereference of p @libraries/liblutil/avl.c @Intraprocedural Null error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? This is definitely a bad programming practice. Can rdn be NULL? @orange @238 orange (INCONSISTENT USE) Possible null dereference of variable rdn+iAVA. This variable is checked for Null at lines: 240 @servers/slapd/dn.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? This is definitely a bad programming practice. Can dn be NULL? @orange @1202 orange (INCONSISTENT USE) Possible null dereference of variable dn. This variable is checked for Null at lines: 1204 @servers/slapd/dn.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? This is definitely a bad programming practice. Can suffix be NULL? @orange @1202 orange (INCONSISTENT USE) Possible null dereference of variable suffix. This variable is checked for Null at lines: 1205 @servers/slapd/dn.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like a bug. @red @634 red Possible NULL dereference of avl_list+ciltmp @libraries/liblutil/avl.c @Intraprocedural Null error ---------------------------------------------------------------- Thx, -- Domagoj Babic http://www.domagoj.info/ http://www.calysto.org/

2 2

(ITS#5102) back-perl build issues
by kurt＠OpenLDAP.org 22 Aug '07

22 Aug '07

Full_Name: Kurt Zeilenga Version: HEAD OS: Mac OS X 10.4.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.180.46.200) Submitted by: kurt With perl v5.8.8 from macports (recently upgraded) Entering directory `/Users/kurt/Work/devel/servers/slapd/back-perl' /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -I/opt/local/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/local/include -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include -I/usr/pkg/include/db45 -c init.c cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -I/opt/local/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/local/include -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include -I/usr/pkg/include/db45 -c init.c -o init.o init.c:90: error: parse error before 'ConfigReply' init.c: In function 'perl_back_db_init': init.c:92: error: number of arguments doesn't match prototype proto-perl.h:27: error: prototype declaration init.c:93: error: 'be' undeclared (first use in this function) init.c:93: error: (Each undeclared identifier is reported only once init.c:93: error: for each function it appears in.) init.c: At top level: init.c:106: error: parse error before 'ConfigReply' init.c: In function 'perl_back_db_open': init.c:108: error: number of arguments doesn't match prototype proto-perl.h:28: error: prototype declaration init.c:112: error: 'be' undeclared (first use in this function) make[3]: *** [init.lo] Error 1

1 0

Re: (ITS#5024) Disabling pagedResults advertisements
by ando＠sys-net.it 22 Aug '07

22 Aug '07

v_orgos(a)yahoo.com.au wrote: > I am upgrading from 2.0.xx (RHEL3) to 2.2.13 on RHEL4. Outlook 2003 clients have > been using the old ldap server with no issues at all but during testing on the > new RHEL4 test server I've come across the problem discussed at First of all, upgrade to 2.3. > http://www.openldap.org/lists/openldap-software/200408/msg00298.html > > As suggested I've tried to stop it advertising pagedResults but it does not > work. > > I've tried > > access to dn.exact="" filter="(supportedControl=1.2.840.113556.1.4.319)" > by * none This would filter out the whole rootDSE, but supportedControl has no matching rule. > > but this does not work and I've tried > > ccess to dn.exact="" attrs=supportedControl val=1.2.840.113556.1.4.319 > by * none This doesn't work because supportedControl has no matching tule > which seg faults. It's a pity that you discovered this so late; if you found it when 2.2. was the latest, we could have fixed it. > I would appreciate if you would provide me with the correct syntax or some means > to allow Outlook to work correctly. The real fix would be to dismiss Outlook. A workaround for OpenLDAP 2.2 is access to dn.exact="" attrs=supportedControl val.regex="^1\.2\.840\.113556\.1\.4\.319$" by * none The "right" syntax for 2.3 is access to dn.exact="" attrs=supportedControl val/objectIdentifierMatch="1.2.840.113556.1.4.319" by * none > I really do not want to have to maintain a custom RPM or have to patch RedHat's > everytime there is an update/security patch. You won't get too many updates from RedHat anyway... 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5101) Fatal Error: call to undefined function ldap_connect()
by rharirakdhanu＠gmail.com 21 Aug '07

21 Aug '07

Full_Name: Hariharan R Version: OS: Windows server 2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.164.140.2) Hi, I am using openldap with php. I am getting, fatal error:call to undefined function ldap_connect()...I modified the php.ini file removing the ; in extension ldap.dll.... But still i get the same error...Could anybody help me to resolve this...I also need step by step procedure to configure Openldap once again with php... Thanks Hariharan.

1 0

Re: Calysto v1.5 reports on openldap_v2.4.4alpha
by Pierangelo Masarati 21 Aug '07

21 Aug '07

Domagoj Babic wrote: > Pierangelo, > > I didn't understand the last part on marking submissions private. > Pardon my ignorance. Could you please elaborate? Please keep replies on the list. >> For this purpose, the ITS allows to mark submissions as PRIVATE. You posted to the openldap-bugs mailing list. This list is for discussion about bugs; but to track issues, like a bug report (as yours seems to be) you're supposed to file an ITS using the ITS interface <http://www.openldap.org/its/>. This is necessary to keep track of the status of your submission, otherwise it's just a bunch of emails, eventually destined to the bin. When you submit a bug, you can mark it as PRIVATE. This means that the bug will only be visible to authorized users (essentially, OpenLDAP developers). A PRIVATE ITS means it's only temporarily private, until the issue is solved; after that, all the traffic about that ITS becomes public. This feature is solely intended to deal with issues that may potentially represent a threat to data security, or system vulnerabilities. For example, if your static scan just checks for NULL pointer dereferencing, without considering the context, as Kurt and Howard already pointed out you could find that hundreds of occurrences that a test client does not check malloc(3) results without being harmful, and one occurrence of the server not checking a pointer at the culprit of dealing with requests. In the latter case, until fixed this would expose all deployments of OpenLDAP to denial of service, but it could go unnoticed because clobbered by the rest. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

3 10

Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by donn＠u.washington.edu 21 Aug '07

21 Aug '07

On Aug 20, 2007, at 12:32 PM, Howard Chu wrote: > Donn Cave wrote: >> On Aug 10, 2007, at 2:16 PM, Howard Chu wrote: >>> Now fixed in HEAD, please test. >> Aug 10 15:06:55 rufus03 slapd[31488]: null_callback : error code 0x14 >> Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101 >> be_modify (20) >> Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101 >> be_modify failed (20) >> I could put some more research into this, but tell me if this >> doesn't make sense. Suppose this mysteriously swapped order: >> a,b,... >> b,a,... >> Your fix increments the first list's index, so next iteration it's >> b,... >> b,a,... >> which is fine, but next iteration is >> ... >> a,... >> "a" looks new at this point, and I try to add it, but it isn't new - >> we just forgot that it was in "old" - and I get error 0x14 >> (LDAP_TYPE_OR_VALUES_EXISTS) > > OK, this should be working now. No joy here. Arguably worse - I think you will find that this one will fail for same-order cases where the original code worked. 1. a,b x,b -> del a, ++i 2. b x,b -> ++i, add x, ++j 3. () b -> add b (oops, b already present.) It looks easy enough to me to code up an order independent version that will actually work. I would initialize adds[] and dels[] with old & new berval pointers, iterate through dels[] and adds[] (nested), and clear both on match. The code is easier to follow and empirically I see one fewer matches in the cases I tested it on. But that's just a test of the algorithm - I haven't sorted out what needs to be done at the end of the function where mcur etc. are modified depending on i == j. Donn Cave, donn(a)u.washington.edu

1 0

(ITS#5100) libldap allows controls to have NULL oid
by ando＠sys-net.it 21 Aug '07

21 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando In fact, ldap_control_dup() is willing to duplicate a control with NULL oid; this is used by ldap_controls_dup(), which is the means used to set/get controls using the ldap_set_option()/ldap_get_option() interface. Since the LDAPOID field in controls is mandatory (RFC 4511), I think those functions should actually error out if they find a missing oid. p.

1 0

Calysto v1.5 reports on openldap_v2.4.4alpha
by Domagoj Babic 21 Aug '07

21 Aug '07

Hi, I ran my static checker Calysto on openldap v2.4.4alpha. Here are the results. Could you please check them out and replace ??? with Yes/No, and if it's a false positive, write a short explanation. calysto v1.5 on openldap_v2.4.4alpha: ??/20 *** Analyzing clients_tools_ldapcompare.bc *** ------------------------------------------ Possible NULL-ptr deref (vc148): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:1334 Bug: ??? Explanation: ber_strdup call (common.c:734) can return NULL, which is dereferenced in strlen call (@742) ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc162): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:921 Bug: No Explanation: Pointer arithmetic + lazy summary expansion ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc192): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:846 Bug: ??? Explanation: ber_strdup call (ldapcompare.c:136) can return NULL, which is dereferenced in strchr call on the next line. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc209): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/sasl.c:53 Bug: ??? Explanation: lutil_sasl_defaults call (@common.c:1060) can return NULL, which is passed to lutil_sasl_freedefs (@1071), which dereferences it (@sasl.c:53). ------------------------------------------ *** Analyzing clients_tools_ldapmodify.bc *** ------------------------------------------ Possible NULL-ptr deref (vc1789): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:1909 Bug: ??? Explanation: ber_strdup call (@fetch.c:62) can return NULL, which is dereferenced by fopen (@65). ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc1791): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/ldif.c:868 Bug: ??? Explanation: ber_memalloc call (@ldif.c:867) can return NULL, which is dereferenced on the next line. ------------------------------------------ *** Analyzing clients_tools_ldapsearch.bc *** ------------------------------------------ Possible NULL-ptr deref (vc3851): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/base64.c:157 Bug: ??? Explanation: ldap_parse_reference call (@ldapsearch.c:1394) calls ldap_pvt_get_controls (@references.c:116), which can set ctrls[i]->ldctl_value.bv_val to NULL and return LDAP_SUCCESS. Later, in the call chain: tool_print_ctrls (@ldapsearc.c:1411) -> lutil_b64_ntop (@common.c:1636) ctrls[i]->ldctl_value.bv_val is received as parameter src, which is dereferenced @base64.c:157. If it helps, my trace says that the first test (@129) fails and that the value of ctrls[i]->ldctl_value.bv_len is 1. Don't know if that's relevant or not. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc3852): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/base64.c:178 Bug: ??? Explanation: ber_memalloc call (@common.c:1634) can return NULL, which is passed to lutil_b64_ntop (@1636), which dereferences it @base64.c:178. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc3853): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/base64.c:130 Bug: ??? Explanation: Seems like a duplicate of vc3851, but according to this trace, it seems that src can be uninitialized. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc3929): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:922 Bug: ??? Explanation: Seems like ctrls[i]->ldctl_oid, dereferenced @common.c:1671) can be uninitialized. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc4342): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/ldif.c:718 Bug: No Explanation: pointer arithmetic + lazy summary expansion ------------------------------------------ *** Analyzing libraries_liblber_etest.bc *** ------------------------------------------ Possible NULL-ptr deref (vc7): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:212 Bug: ??? Explanation: getbuf call (@etest.c:151) can return NULL, which atoi dereferences on the next line. ------------------------------------------ *** Analyzing libraries_libldap_ltest.bc *** ------------------------------------------ Possible NULL-ptr deref (vc44): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/libldap/test.c:778 Bug: ??? Explanation: Seems like vals[i]->bv_val can remain uninitialized. ------------------------------------------ *** Analyzing libraries_librewrite_rewrite.bc *** ------------------------------------------ Possible NULL-ptr deref (vc4622): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/avl.c:289 Bug: ??? Explanation: It seems that rewrite_info_init @rewrite.c:52 call can return a valid info, but leave info->li_params->avl_link[0] uninitialized. info is then passed to rewrite_read @54, which passes it to rewrite_parse @parse.c:112, which passes it to rewrite_param_set @config.c:283, which passes &info->li_params to rewrite_var_insert_f @params.c:51 (received as pointer tree). p is initialized with *tree @190. If nside==0, p->avl_link[0] is dereferenced @289. Note that Calysto finds _a trace_, not _the shortest_ trace. So, perhaps this would fail sooner. Related problem: rewrite_info_init call @rewrite.c:52 can return NULL, which is then passed to rewrite_read @54, which calls rewrite_parse @parse.c:112. rewrite_parse has an assertion that will fail @config.c:59. The pointer returned by rewrite_info_init should be checked right away, and if NULL exit with an appropriate msg. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc4626): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/avl.c:308 Bug: ??? Explanation: Seems like r->avl_link can be NULL. Trace is equally long to vc4622, but the control flow context is somewhat more complicated, so I'm leaving that out. ------------------------------------------ *** Analyzing servers_slurpd_slurpd.bc *** ------------------------------------------ Possible NULL-ptr deref (vc216): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:869 Bug: ??? Explanation: CATLINE(buf) is called @config.c:427, but it can fail to initialize line. The trace shows that lcur+len+1 can result in an integer overflow, in which case the test @403 would fail, and line would not be initialized. Later, line is dereferenced @445. ------------------------------------------ *** Analyzing tests_progs_slapd-bind.bc *** ------------------------------------------ Possible NULL-ptr deref (vc27): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-common.c:176 Bug: ??? Explanation: ldap_str2charray call (@slapd-common.c:174) can return NULL, which is dereferenced two lines lower. ------------------------------------------ *** Analyzing tests_progs_slapd-tester.bc *** ------------------------------------------ Possible NULL-ptr deref (vc59): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-tester.c:277 Bug: ??? Explanation: ldap_str2charray call (@slapd-tester.c:275) can return NULL, which is dereferenced two lines lower. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc62): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-tester.c:224 Bug: ??? Explanation: ldap_str2charray call (@slapd-tester.c:218) can return NULL, which is dereferenced @224. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc64): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-tester.c:226 Bug: ??? Explanation: calloc call (@slapd-tester.c:225) can return a NULL pointer, which is dereferenced on the next line. ------------------------------------------ Thx, -- Domagoj Babic http://www.domagoj.info/ http://www.calysto.org/

4 10

Re: openldap-2.3.37 configure can not find openssl/ssl.h (ITS#5099)
by ando＠sys-net.it 21 Aug '07

21 Aug '07

y.le.ny(a)ifrance.com wrote: >> the file openssl/ssl.h cannot be located on your system. Apparently, >> it's not where you expect it to be, > I verify, the path is OK. > >> or CPPFLAGS are not being read as >> expected by configure. I'm more inclined towards the latter, as no "-I" >> appears in the cc commands in your log. > Any idea to test this case or > force configure to use the variables that are in CPPFLAGS ? depending on the shell you're using, I'd export the variables and then run configure. For bash (which I use): export CPPFLAGS="-I /path ..." export LDFLAGS="-L /path ..." ./configure --enable-... In any case, I don't see this as a bug in any of OpenLDAP's components. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: openldap-2.3.37 configure can not find openssl/ssl.h (ITS#5099)
by y.le.ny＠ifrance.com 20 Aug '07

20 Aug '07

>the file openssl/ssl.h cannot be located on your system. Apparently, >it's not where you expect it to be, I verify, the path is OK. >or CPPFLAGS are not being read as >expected by configure. I'm more inclined towards the latter, as no "-I" >appears in the cc commands in your log. Any idea to test this case or force configure to use the variables that are in CPPFLAGS ?

1 0

Re: openldap-2.3.37 configure can not find openssl/ssl.h (ITS#5099)
by ando＠sys-net.it 20 Aug '07

20 Aug '07

Yannick LE NY wrote: > Sorry, but at works, I can use only webmail and > I have no options to send my e-mail in text mode only. Well, I'm sorry but the ITS can't handle MIME messages. > I send you my config.log in an other e-mail for you only. > I found nothing in this file for the openssl headers problem. Well, I've found plenty: <snip> configure:19446: checking openssl/ssl.h usability configure:19458: cc -c -g -O2 conftest.c >&5 conftest.c:124:25: openssl/ssl.h: No such file or directory </snip> <snip> | #include <openssl/ssl.h> configure:19487: result: no configure:19491: checking openssl/ssl.h presence configure:19501: cc -E conftest.c conftest.c:90:25: openssl/ssl.h: No such file or directory </snip> <snip> | #include <openssl/ssl.h> configure:19527: result: no configure:19562: checking for openssl/ssl.h configure:19569: result: no configure:19821: error: Could not locate TLS/SSL package </snip> the file openssl/ssl.h cannot be located on your system. Apparently, it's not where you expect it to be, or CPPFLAGS are not being read as expected by configure. I'm more inclined towards the latter, as no "-I" appears in the cc commands in your log. >> As per the request to add configure switches to locate common packages, it >> should be rejected, as the appropriate way to let compilers detect > packages is >> by CPPFLAGS, LDFLAGS, LD_LIBRARY_PATH. > Ok, that is your choice That's the project's choice, not mine, although I find it reasonable. > but configure switches to locate common packages represent a broken means to > help users to compile openldap. as they do not allow, for example, to sort the order in which paths should be searched and so. > Sometimes users don't know how to > configure CPPFLAGS, LDFLAGS, LD_LIBRARY_PATH for their environnment > because there are administrators but not developpers. That's another business. In this case, administrators could use bundled packages instead of building their own. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: openldap-2.3.37 configure can not find openssl/ssl.h (ITS#5099)
by y.le.ny＠ifrance.com 20 Aug '07

20 Aug '07

Sorry, but at works, I can use only webmail and I have no options to send my e-mail in text mode only. I send you my config.log in an other e-mail for you only. I found nothing in this file for the openssl headers problem. >As per the request to add configure switches to locate common packages, it >should be rejected, as the appropriate way to let compilers detect packages is >by CPPFLAGS, LDFLAGS, LD_LIBRARY_PATH. Ok, that is your choice but configure switches to locate common packages help users to compile openldap. Sometimes users don't know how to configure CPPFLAGS, LDFLAGS, LD_LIBRARY_PATH for their environnment because there are administrators but not developpers. Thanks for your help. ++++++++++++++++++++++++++ Pierangelo Masarati wrote : > y.le.ny(a)ifrance.com wrote: > >> This is a multi-part message in MIME format. >> >> ----------------3f8620ff6596fbde5a10880e48d84784 >> Content-Type: multipart/alternative; >> boundary="--------------a4aca1475551c759da8fba68bbada551" >> >> >> ----------------a4aca1475551c759da8fba68bbada551 >> Content-Type: text/plain; charset="utf-8" >> Content-Transfer-Encoding: base64 >> >> SGVsbG8sCgpJIHNlbmQgeW91IG15IGNvbmZpZy5sb2cuCkkgZm91bmQgbm90aGluZyBpbiB0aGlz >> > <snip> > > Please do not send html messages to the ITS. > > 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 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > > > >

1 0

Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by hyc＠symas.com 20 Aug '07

20 Aug '07

Donn Cave wrote: > On Aug 10, 2007, at 2:16 PM, Howard Chu wrote: >> Now fixed in HEAD, please test. > > Aug 10 15:06:55 rufus03 slapd[31488]: null_callback : error code 0x14 > Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101 > be_modify (20) > Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101 > be_modify failed (20) > > I could put some more research into this, but tell me if this > doesn't make sense. Suppose this mysteriously swapped order: > a,b,... > b,a,... > > Your fix increments the first list's index, so next iteration it's > b,... > b,a,... > > which is fine, but next iteration is > ... > a,... > > "a" looks new at this point, and I try to add it, but it isn't new - > we just forgot that it was in "old" - and I get error 0x14 > (LDAP_TYPE_OR_VALUES_EXISTS) OK, this should be working now. -- -- Howard Chu Chief Architect, 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#5097) slapo-refint apply to subtree renaming
by ando＠sys-net.it 20 Aug '07

20 Aug '07

zhangweiwu(a)realss.com wrote: > It would be nice if referential integrity is maintained during subtree > renaming. This is now fixed in HEAD. Please test. 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 Email: pierangelo.masarati(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