openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5369) GSSAPI support for client library
by kurt＠OpenLDAP.org 11 Feb '08

11 Feb '08

On Feb 11, 2008, at 1:09 AM, mimir(a)samba.org wrote: > Full_Name: Rafal Szczesniak > Version: HEAD > OS: GNU/Linux > URL: http://www.samba.org/~mimir/gssapi-head.diff The submitted patch file does not contain (at the top of the file, not as part of the diffs) the required notices. Please review http://www.openldap.org/devel/contributing.html and insert appropriate notices. Also, please don't include in the diffs derived files (e.g., configure). -- Kurt

1 0

(ITS#5370) race condition in slap_op_time()
by h.b.furuseth＠usit.uio.no 11 Feb '08

11 Feb '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE23, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd/operation.c:slap_op_time() can decrease last_time: thread 1: *t = slap_get_time(); <clock: increment time()> thread 2: *t = slap_get_time(); thread 2: with mutex lock: increment last_time, set last_incr = 0; thread 1: with mutex lock: decrement last_time, set last_incr = 0; The simplest fix is to move the slap_get_time() call inside the (global) slap_op_mutex lock. However as far as I can tell, only the accesslog overlay uses op->o_tincr, the value which needs the mutex. And accesslog calls slap_op_time() itself when it needs that value. So maybe we should remove the op->o_tincr field. Other calls to slap_op_time() can be replaced with slap_get_time().

1 0

Re: (ITS#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 11 Feb '08

11 Feb '08

h.b.furuseth(a)usit.uio.no writes: > Also, now that I think of it, back-hdb/ldif subtree rename is broken if > there are referral objects with DNs in the subtree. Duh, that's a feature, not a bug. If a referral entry gets renamed, that does not magically rename the entry it refers to. It gets to be a bug if one has cooperating servers where they all rename the entry. Anyway, getting back to back-bdb - once the database has a ref attribute with a DN, I don't see how rewriting it is worse than not rewriting. So I think the fix for now is to to follow the RFCs. -- Hallvard

1 0

(ITS#5369) GSSAPI support for client library
by mimir＠samba.org 11 Feb '08

11 Feb '08

Full_Name: Rafal Szczesniak Version: HEAD OS: GNU/Linux URL: http://www.samba.org/~mimir/gssapi-head.diff Submission from: (NULL) (12.104.75.4) OpenLDAP client libraries do not implement convenient mechanisms for interfacing to MS Active Directory with minimum necessary configuration. Also, SASL implementation is tightly connected with Cyrus SASL libs. Submitted patch modifies the library to provide more generic SASL layer used both by Cyrus SASL and contributed GSSAPI mechanism. The GSSAPI itself is limited to Kerberos 5, at the moment, but the goal is to provide complete SASL layer for easy connecting to MS servers.

1 0

Re: (ITS#5368) s/strncasecmp/ber_bvstrncasecmp/ broke substring check for {CLEARTEXT}
by hyc＠symas.com 10 Feb '08

10 Feb '08

steve.langasek(a)canonical.com wrote: > Full_Name: Steve Langasek > Version: 2.4.7 > OS: Debian > URL: http://people.ubuntu.com/~vorlon/sasl-cleartext-strncasecmp.patch > Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb) > > > A regression was introduced in revision 1.239 of servers/slapd/sasl.c. > Previously, sasl_ap_lookup() would check for a leading string of {CLEARTEXT} and > trim it from the userPassword value returned to SASL; but in revision 1.239, the > strncasecmp() was replaced with ber_bvstrcasecmp() which instead looks for an > exact match of the whole string, causing passwords to be handed back to SASL > with the leading "{CLEARTEXT}" attached. > > The referenced patch is verified to correct this regression. Thanks, this is now fixed in HEAD. -- -- 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

(ITS#5368) s/strncasecmp/ber_bvstrncasecmp/ broke substring check for {CLEARTEXT}
by steve.langasek＠canonical.com 10 Feb '08

10 Feb '08

Full_Name: Steve Langasek Version: 2.4.7 OS: Debian URL: http://people.ubuntu.com/~vorlon/sasl-cleartext-strncasecmp.patch Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb) A regression was introduced in revision 1.239 of servers/slapd/sasl.c. Previously, sasl_ap_lookup() would check for a leading string of {CLEARTEXT} and trim it from the userPassword value returned to SASL; but in revision 1.239, the strncasecmp() was replaced with ber_bvstrcasecmp() which instead looks for an exact match of the whole string, causing passwords to be handed back to SASL with the leading "{CLEARTEXT}" attached. The referenced patch is verified to correct this regression.

1 0

Re: (ITS#5361) cert verification failures with GnuTLS and DNS subjectAltName
by steve.langasek＠canonical.com 10 Feb '08

10 Feb '08

On Sun, Feb 10, 2008 at 01:19:49AM -0800, Howard Chu wrote: >> It's true that the /length/ of a string doesn't include the trailing NUL, >> but it does have to be included in the storage /size/ of a C string, and >> it's debatable which is intended here. > Since this is an ASN.1 structure, one would ordinarily not expect any NUL > termination in the first place. And since other GnuTLS library functions > are returning the raw data size, excluding any trailing NUL, the behavior > you're seeing here is pretty suspicious. Well, granted; it is consistent in newer versions of GnuTLS, though, despite being inconsistent with older versions and with the other crt APIs. >> Given that one of the errors >> returned by gnutls_x509_crt_get_subject_alt_name() is >> GNUTLS_E_SHORT_MEMORY_BUFFER, it seems obvious to me that this should use >> semantics for storage size rather than string length, and the only question >> in my mind is whether the trailing NUL is included as part of the internal >> representation of the string. >> If this is a behavior change as you say, then I guess we need clarification >> from GnuTLS upstream about whether this is intentional. > That sounds like the best step for now. Just to be sure, how was the > certificate created? Using the openssl commandline tool, and specifying a subjectAltName=DNS:hostname entry in the [ v3_ca ] section of /etc/ssl/openssl.cnf. This was created strictly as a test certificate, in response to reports of problems precisely with subjectAltName validation (http://bugs.debian.org/462588#98). > Have you verified that libldap with OpenSSL accepts the certificate > correctly? Yes, I've tested with ldapsearch from OpenLDAP 2.3.30 linked against OpenSSL, which was able to validate the subjectAltName just fine. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org

1 0

Re: (ITS#5367) test019-syncreplication-cascade fails
by hyc＠symas.com 10 Feb '08

10 Feb '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux x86_64 > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080210.tgz.1 > Submission from: (NULL) (129.240.203.232) > Submitted by: hallvard > > > "./run test019-syncreplication-cascade" fails in HEAD: > master and R2 slave databases differ Sorry about that, was poking at things that didn't need poking. Fixed in HEAD. > diff testrun/server1.out testrun/server3.out says server3 has an extra object > cn=James A Jones 2,ou=Information Technology > Division,ou=People,dc=example,dc=com > > testrun directory in enclosed, including test output in testrun/output. > > (Ignore the ftp'ed filename without ".1" at the end, transfer failed.) > > > . > -- -- 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

(ITS#5367) test019-syncreplication-cascade fails
by h.b.furuseth＠usit.uio.no 10 Feb '08

10 Feb '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080210.tgz.1 Submission from: (NULL) (129.240.203.232) Submitted by: hallvard "./run test019-syncreplication-cascade" fails in HEAD: master and R2 slave databases differ diff testrun/server1.out testrun/server3.out says server3 has an extra object cn=James A Jones 2,ou=Information Technology Division,ou=People,dc=example,dc=com testrun directory in enclosed, including test output in testrun/output. (Ignore the ftp'ed filename without ".1" at the end, transfer failed.)

1 0

(ITS#5366) ldap_get_dn man page errors
by rra＠stanford.edu 10 Feb '08

10 Feb '08

Full_Name: Russ Allbery Version: 2.4.7 OS: Debian GNU/Linux URL: Submission from: (NULL) (171.66.157.14) The ldap_get_dn man page has the following prototype for ldap_str2dn: int ldap_str2dn( const char *str, LDAPDN **dn, unsigned flags ) However, ldap.h has: LDAP_F( int ) ldap_str2dn LDAP_P(( LDAP_CONST char *str, LDAPDN *dn, unsigned flags )); Note the difference for the second argument. This is related to, later in the man page: typedef struct ldap_ava { char *la_attr; struct berval *la_value; unsigned la_flags; } LDAPAVA; typedef LDAPAVA** LDAPRDN; typedef LDAPRDN** LDAPDN; but ldap.h says: typedef struct ldap_ava { struct berval la_attr; struct berval la_value; unsigned la_flags; void *la_private; } LDAPAVA; typedef LDAPAVA** LDAPRDN; typedef LDAPRDN* LDAPDN; Note the type difference for LDAPDN (which explains the earlier varience) and for la_attr. Original Debian bug report: http://bugs.debian.org/465024

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