openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#6924) www.openldap.org and git.openldap.org serve different repositories
by ondra＠mistotebe.net 11 Oct '11

11 Oct '11

Note that openldap.git is not the only repository serving different history, e.g.: ---------------- 8< ---------------- $ git clone http://www.openldap.org/software/repo/openldap-jldap.git openldap-jldap.http $ cd openldap-jldap.http $ git log -1 commit 07fc2a4b6f20dfb3a171ee0fa4b66082358b8b53 Author: Nachiappan Palaniappan <npalani(a)openldap.org> Date: Mon Jul 6 08:43:38 2009 +0000 Updated version to 4.6. ---------------- 8< ---------------- Compare it to: ---------------- 8< ---------------- $ git clone git://git.openldap.org/openldap-jldap.git openldap-jldap.git $ cd openldap-jldap.git $ git log -1 commit bae9f556e97ad5bb0f76fe897c9b298a6021e244 Date: Mon Jul 6 08:43:38 2009 +0000 Updated version to 4.6. ---------------- 8< ---------------- Cheers, Ondrej Kuznik

1 0

(ITS#7061) Only return requested attrs in sssvlv response
by ctcard＠hotmail.com 11 Oct '11

11 Oct '11

Full_Name: Chris Card Version: 2.4.26 + patch OS: Centos 5.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.194.158.133) There was a fix put into master on 18 Jul 2011 with subject "Only return requested attrs in sssvlv response" SHA: 8eecc9a017584ea0b56b25f0e4750e3b16929de6. I have patched openldap 2.4.26 with all the fixes to sssvlv.c, but there is still an issue with the attributes returned in an sssvlv response. On the first sssvlv request only the requested attributes are returned, but on subsequent sssvlv requests using the vlv context returned by the first requests, all the attributes are returned.

1 0

(ITS#7060) Bad compare results with back-sock (and I suspect back-shell)
by maurice＠perry.ch 09 Oct '11

09 Oct '11

Full_Name: Maurice Perry Version: 2.4.26 OS: Linux (debian) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (160.53.250.126) The result code returned for the COMPARE operation with back-sock. The problem is due to a bug (two actually) in function str2result in servers/slapd/result.c: while ( isspace( (unsigned char) next[ 0 ] ) ) next++; if ( next[ 0 ] != '\0' ) { Debug( LDAP_DEBUG_ANY, "str2result (%s) extra cruft after value\n", s, 0, 0 ); rc = -1; continue; } /* FIXME: what if it's larger that max int? */ *code = (int)retcode; The code is not set properly if the code is not the last line of the result. I corrected the issue as follows: while ( isspace( (unsigned char) next[ 0 ] ) && next[ 0 ] != '\n' ) next++; if ( next[ 0 ] != '\0' && next[ 0 ] != '\n' ) { Debug( LDAP_DEBUG_ANY, "str2result (%s) extra cruft after value\n", s, 0, 0 ); rc = -1; continue; } /* FIXME: what if it's larger that max int? */ *code = (int)retcode;

1 0

(ITS#7059) UTF8StringNormalize will overrun a zero-length value
by hyc＠OpenLDAP.org 06 Oct '11

06 Oct '11

Full_Name: Howard Chu Version: 2.4.x OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc According to the commit history this bug has been present since 2003-04-07 (commit 67d6b23d). A patch is in git master, but I'm continuing to investigate and will update it further.

1 0

Re: (ITS#6979) test062 portability
by richton＠nbcs.rutgers.edu 04 Oct '11

04 Oct '11

On Fri, 30 Sep 2011, Hallvard B Furuseth wrote: > I'm curious, what is this about - an observed bug, or not? There is > no function call here, 'wait' is checking a subprocess's exit status. > That's standard, and so is checking the return (not exit) status from > a function as far as I know, but I'm not surprised if some shells have > quirks. At the time I actually saw this on Solaris /bin/sh. I'll hopefully pull down a fresh copy and re-examine in a few days (I'm a bit backlogged at the moment trying to cram things in before I head to LDAPCon).

1 0

(ITS#7055) pwcheck Module for slapo-ppolicy
by lukas.graesslin＠collax.com 01 Oct '11

01 Oct '11

Full_Name: Lukas Grässlin Version: Latest Git OS: Arch Linux URL: http://dl.dropbox.com/u/32193848/src/0001-Added-pwcheck-module-for-the-slap… Submission from: (NULL) (88.67.244.45) Hi there, I wrote a new pwcheck module for the slapo-ppolicy overlay which is able to handle multiple different policies. My problem was: I have multiple password policies which are applied to different users. The policies differ in strength etc. The problem was that with the only pwcheck modul you can find on the net (https://ltb-project.org/svn/openldap-ppolicy-check-password/trunk/) you just define one 'policy-thing' which will be checked if check-password.so is run. I wanted to have something were you also can define multiple policies which also can differ, so I wrote my own module which reads two config files: $CONFDIR/ppolicies: There are the policies defined. Example: [Default] min_len = 8 min_digit = 1 min_lower = 1 min_special = 1 min_upper = 1 $CONFDIR/users: These file holds the relation between users and policies: uid=lukas,ou=People,dc=example,dc=com : Default Well, it would have been nicer if that policy definition & co would also be stored in ldap, but the config-file-way was the faster one as it had to be finished quick. Whatever, maybe some of you could need this or improve it.

1 0

RE: (ITS#7051) ldap_pvt_tls_get_peer_dn fails under gnutls
by Giampaolo＠Tomassoni.biz 30 Sep '11

30 Sep '11

> > This is the needed patch: > > This patch should not work either, you still need a skip_tag before the > get_int. > > > - tag = ber_skip_tag( ber,&len ); /* Context + > Constructed > > (version) */ > > + tag = ber_peek_tag( ber,&len ); /* Context + > Constructed I confirm this patch worked for me, at least it did on an amd64 I'm working on. It worked both with openssl-generated v1 (no version tag present) and v3 certificates (version tag present). I don't know if this is an cpu-architecture -dependent issue (I don't think so), nor I know how the ber_* library works, but FWICU the Context + Constructed stuff is handled as a tag prefix by the ber_get_int(), which then discards it when found and fetches the encapsulated value. Instead, ber_peek_tag() is probably more simple-minded in that it peeks the first word at the buffer pointer, which is the Context + Constructed prefix, not really the tag. I can of course be wrong, but with this patch I got i==2 from v3 certificates, which is the correct value. Giampaolo

1 0

Re: (ITS#6979) test062 portability
by h.b.furuseth＠usit.uio.no 30 Sep '11

30 Sep '11

Aaron Richton writes: > It looks like checking the function exit isn't portable; maybe some > kind of bash-ism. It looks like the code was on the path to > communicating the retval via $RCOUT file already? I'm curious, what is this about - an observed bug, or not? There is no function call here, 'wait' is checking a subprocess's exit status. That's standard, and so is checking the return (not exit) status from a function as far as I know, but I'm not surprised if some shells have quirks. I noticed because I saw the patch entering master. Which is fine by me, except the patch may be a bit incomplete. Since $SEARCHRC is now the output from `cat`, it may be best to quote it here: > if test $SEARCHRC != 52 ; then -- Hallvard

1 0

Re: (ITS#7006) openldap does not accept wildcard certificates with mozilla/nss
by hyc＠symas.com 30 Sep '11

30 Sep '11

hash_oldap(a)cycdolphin.net wrote: > Full_Name: Philippe Kueck > Version: 2.4.23 / 2.4.26 > OS: RHEL 6.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.98.65.86) > > > When compiled against Mozilla/NSS OpenLDAP does not accept wildcard > certificates. > > This is probably because in tls_m.c the certificate CN (*.domain.example) is > matched against the hostname (foo.domain.example), not against the domain > (.domain.example). > > I suggest the following patch: Thanks for the report, fixed in master. > > --%snip%-- > diff -Nru openldap-2.4.26-orig/libraries/libldap/tls_m.c > openldap-2.4.26/libraries/libldap/tls_m.c > --- openldap-2.4.26-orig/libraries/libldap/tls_m.c 2011-06-30 17:13:36.000000000 > +0200 > +++ openldap-2.4.26/libraries/libldap/tls_m.c 2011-08-01 16:29:42.000000000 > +0200 > @@ -2590,7 +2590,7 @@ > if ( av->len == nlen&& !strncasecmp( name, (char *)av->data, nlen )) { > ret = LDAP_SUCCESS; > } else if ( av->data[0] == '*'&& av->data[1] == '.'&& > - domain&& dlen == av->len - 1&& !strncasecmp( name, > + domain&& dlen == av->len - 1&& !strncasecmp( domain, > (char *)(av->data+1), dlen )) { > ret = LDAP_SUCCESS; > } else { > --%snip%-- > > > Kind regards, > > Philippe Kueck > > -- -- 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#7011) signal 6 got in ldap_abandon
by hyc＠symas.com 30 Sep '11

30 Sep '11

ogermain(a)tibco.com wrote: > Full_Name: Olivier GERMAIN > Version: 2.4.24 > OS: Solaris 5.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.157.248.2) > > > Dear All, > > One of our customer got a signal 6 during the execution of the ldap_abandon. > This signal occurred whereas some maintenance was doing on a firewall which is > not located on the same network. It seems that the ldap_abandon thrown this > assert because it was a situation like a can't happen. I don't have much > information on the action performed on the firewall which led to this sigabort. > > > Please find the logs I have : > 2011-07-19 04:08:52.876909|ENG|FATAL|84|engine.cpp(109)| > /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/distrib/kabira/lib/libsyssrv.so:sw_debugSignalHandler+0x18 > 2011-07-19 04:08:52.877541|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:<static-func>+0x5b0 > 2011-07-19 04:08:52.878082|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:<static-func>+0x628 > 2011-07-19 04:08:52.878658|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:_lwp_kill+0x8 [ Signal 6 (SIGABRT) ] > 2011-07-19 04:08:52.879196|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:abort+0xd0 > 2011-07-19 04:08:52.879733|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:_assert+0x74 > 2011-07-19 04:08:52.880325|ENG|FATAL|84|engine.cpp(109)| > /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/3rdparty/sol/openldap/2.4.24_64/lib/libldap-2.4.so.2.6.0:<static-func>+0x4ec > 2011-07-19 04:08:52.880776|ENG|FATAL|84|engine.cpp(109)| > /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/3rdparty/sol/openldap/2.4.24_64/lib/libldap-2.4.so.2.6.0:ldap_abandon+0xac > > I am in the process of a reproduction of this signal 6 but I would like to share > the following idea. > > Do you think there is a possibility to enhance the openldap library to avoid > this assert? Is it possible that instead of having an assert, we have a > exception or a status code which tell us something went wrong of obviously that > we can handle in our source code. An assert means there is a bug, either in your code or ours. Since this part of the library has been around for several years with no issues, that generally means it's a bug in your code. The way to handle this is to fix your code. Trapping or ignoring the conditions that are asserted is just a bad idea. > > My best regards > Olivier GERMAIN > TIBCO Support team > > -- -- 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