openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#7873) slapo-refint interferes with cn=config
by hyc＠OpenLDAP.org 04 Jun '14

04 Jun '14

Full_Name: Howard Chu Version: 2.4.39 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc The refint overlay performs its referential integrity updates in a separately queued thread. On a large database the necessary updates may take a long time, and currently the refint_qtask doesn't check for pending cn=config pause requests. Fix coming shortly.

1 0

(ITS#7872) slapd-mdb memory leak in mdb_entry_get
by hyc＠OpenLDAP.org 04 Jun '14

04 Jun '14

Full_Name: Howard Chu Version: 2.4.39 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Actually the leak is in dn2entry but it only occurs when called from mdb_entry_get. A fix is coming shortly.

1 0

Re: (ITS#6970) OpenLDAP 2.4.25 MemberOf + AutoGroup user has stale "memberof" attributes for target group after removal from trigger group
by ryan＠nardis.ca 04 Jun '14

04 Jun '14

Hi, The last comments on this ITS mentioned crashes or deadlocks when using autogroup and memberof together. I tried this today with git master on both mdb and hdb backends. Adding a new entry that triggers an autogroup member to be added: I don't get a crash or deadlock, but the new entry doesn't have a memberOf attribute. It looks like the internal Modify adding the member happens before the Add completes, so memberof tries to add memberOf to an entry that doesn't exist yet. Changing autogroup to trigger on an alteration to an existing entry, for example addition of a specific attribute or auxiliary objectClass: with mdb this works and the memberOf attribute is added; with hdb I get the same deadlock Landry Breuil already reported. Looks like a recursive deadlock on the same thread. I think those problems are both different from the one this ITS is about, though. Maybe they should be filed separately. I also confirmed the problem originally reported on current git master, and the analysis sounds right, but I haven't had time to think through the proposed solution fully. I'm not totally sure whether it's autogroup or memberof that actually needs fixing. Maybe both. cheers, Ryan

1 0

Re: (ITS#7871) slapcat ldif-wrap option produced wrong column length
by hyc＠symas.com 04 Jun '14

04 Jun '14

mwarren(a)symas.com wrote: > Full_Name: Mark Warren > Version: 2.4.39 > OS: Debian 6 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (72.35.133.119) > > > It appears that the slapcat option '-o ldif-wrap=n' is not properly followed. > > e.g, this: > > slapcat -o ldif-wrap=30 > > will produce a file with 32 columns not including the newline character. Yes, we already detailed this in ITS#7859 followup #1. -- -- 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#7871) slapcat ldif-wrap option produced wrong column length
by mwarren＠symas.com 04 Jun '14

04 Jun '14

Full_Name: Mark Warren Version: 2.4.39 OS: Debian 6 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.35.133.119) It appears that the slapcat option '-o ldif-wrap=n' is not properly followed. e.g, this: slapcat -o ldif-wrap=30 will produce a file with 32 columns not including the newline character. Regards, Mark

1 0

(ITS#7870) slapd-mdb slapcat failure
by hyc＠OpenLDAP.org 04 Jun '14

04 Jun '14

Full_Name: Howard Chu Version: 2.4.39 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc If an index was configured in slapd.conf but not created yet (e.g. slapindex wasn't run) then slapcat will fail because it tried to open the index DB in read-only mode and it doesn't exist yet. slapcat shouldn't even bother to open the index DBs since it doesn't use them. Fix coming shortly.

1 0

(ITS#7869) [PATCH] contrib passwd/apr1 do_phk_hash arguments
by ryan＠nardis.ca 02 Jun '14

02 Jun '14

Full_Name: Ryan Tandy Version: master/33e12f4 RE24/b000d95 OS: Debian unstable URL: Submission from: (NULL) (24.68.121.206) Hi, The apr1 passwd plugin calls do_phk_hash with the arguments in the wrong order, so the digest updates are done in a different order than md5crypt does. The following patch fixes that, restoring compatibility with existing htpasswd files. However, existing {APR1} hashes that were generated while the bug existed are going to be broken... I'm not sure what to do about that. :/ thanks, Ryan >From f9ad46e3c8264ffa1420aa3b24cfc69cae7bed65 Mon Sep 17 00:00:00 2001 From: Ryan Tandy <ryan(a)nardis.ca> Date: Sun, 1 Jun 2014 22:41:23 -0700 Subject: [PATCH] contrib passwd/apr1 fix do_phk_hash arguments --- contrib/slapd-modules/passwd/apr1.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/slapd-modules/passwd/apr1.c b/contrib/slapd-modules/passwd/apr1.c index ce7b8c7..463d8d1 100644 --- a/contrib/slapd-modules/passwd/apr1.c +++ b/contrib/slapd-modules/passwd/apr1.c @@ -143,7 +143,7 @@ static int chk_phk( salt.bv_val = (char *) &orig_pass[sizeof(digest)]; salt.bv_len = rc - sizeof(digest); - do_phk_hash(cred, magic, &salt, digest); + do_phk_hash(cred, &salt, magic, digest); if (text) *text = NULL; @@ -197,7 +197,7 @@ static int hash_phk( for (n = 0; n < salt.bv_len; n++) salt.bv_val[n] = apr64[salt.bv_val[n] % (sizeof(apr64) - 1)]; - do_phk_hash(passwd, magic, &salt, digest_buf); + do_phk_hash(passwd, &salt, magic, digest_buf); if (text) *text = NULL; -- 2.0.0

1 0

(ITS#7868) Sock overlay segfault when reading sockname from configfile
by orcus＠pwr.wroc.pl 02 Jun '14

02 Jun '14

Full_Name: Daniel Dobrijalowski Version: 2.4.39 OS: 2.6.32-431.17.1.el6.centos.plus.x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (156.17.1.3) Hi, servers/slapd/config.c: line 477: if ( *(char **)ptr ) ptr is NULL so it triggers SIGSEGV line: 461: ptr = c->bi->bi_private; bi_private is NULL My knowledge of openldap internals is to weak to find where and if bi_private should be initialized in this case. Steps to reproduce: After downloading openldap-2.4.39 and configuring it with options: ./configure --prefix=/usr/ --enable-slapd --enable-overlays --enable-bdb --enable-meta --enable-monitor --enable-sock --enable-crypt --enable-cleartext --enable-ldap --with-tls=openssl --sysconfdir=/etc I have added only slapo-sock related options at the end of default slapd.conf: overlay sock extensions peername socketpath "/tmp/ldap.sock" sockops bind sockresps result

1 0

Re: (ITS#7867) TLS SHA512
by hyc＠symas.com 31 May '14

31 May '14

yann+openldap(a)verry.org wrote: > Full_Name: Yann Verry > Version: 2.4.39 > OS: debian/sid > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:e35:2e6d:c800:d572:aec:1b42:380c) This is purely a TLS issue, OpenLDAP has nothing to do with it. Ask for help on a gnutls support forum. Closing this ITS. > > > Hi, > > I would like (CACert sign class3 now with SHA512) to switch my X509 certificate > with a signature algorithm SHA512. > When I do this openldap bind on SSL port but was unable to provide SSL > connection as you can see in error: > > 2014-05-31T00:20:46.852821+02:00 peach slapd[23997]: >>> > slap_listener(ldaps:///) > 2014-05-31T00:20:46.853369+02:00 peach slapd[23997]: connection_get(35): got > connid=1068 > 2014-05-31T00:20:46.853891+02:00 peach slapd[23997]: connection_read(35): > checking for input on id=1068 > 2014-05-31T00:20:46.854526+02:00 peach slapd[23997]: connection_read(35): TLS > accept failure error=-1 id=1068, closing > 2014-05-31T00:20:46.855071+02:00 peach slapd[23997]: connection_close: conn=1068 > sd=35 > > If I fall back to sha256 it works fine > > > How to reproduce > ================ > > - generate self signed with sha256 and sha512: > > mkdir -p /etc/ldap/ssl > cd !$ > > # priv > certtool --generate-privkey --sec-param normal --outfile mypriv_normal.key > > # self > certtool -s --load-privkey mypriv_normal.key --outfile gnutls512_normal.crt > --hash SHA512 > certtool -s --load-privkey mypriv_normal.key --outfile gnutls256_normal.crt > --hash SHA256 > > # build PEM > cat mypriv_normal.key gnutls512_normal.crt > gnutls512_normal.pem > cat mypriv_normal.key gnutls256_normal.crt > gnutls256_normal.pem > > > my cn=config: > > olcTLSCACertificateFile: /etc/ldap/ssl/sslcertificate.pem > olcTLSCertificateFile: /etc/ldap/ssl/sslcertificate.pem > olcTLSCertificateKeyFile: /etc/ldap/ssl/sslcertificate.pem > > now just play with symlink. > > sha256 > ------ > > ln -s gnutls256_normal.pem sslcertificate.pem ; then restart openldap > > make a client connection: > > gnutls-cli ldap.verry.org -p 636 > Resolving 'ldap.verry.org'... > Connecting to '2a01:e35:2e6d:c800:cafe:deca:0:42:636'... > - Certificate type: X.509 > - Got a certificate list of 1 certificates. > - Certificate[0] info: > - subject `CN=ldap.verry.org', issuer `CN=ldap.verry.org', RSA key 2432 bits, > signed using RSA-SHA256, activated `2014-05-31 08:26:59 UTC', expires > `2024-05-28 08:27:03 UTC', SHA-1 fingerprint > `600b2a502289644c075d4b3eaf7b1efd38685687' > - The hostname in the certificate matches 'ldap.verry.org'. > - Peer's certificate issuer is unknown > - Peer's certificate is NOT trusted > - Version: TLS1.2 > - Key Exchange: RSA > - Cipher: AES-128-CBC > - MAC: SHA1 > - Compression: NULL > - Handshake was completed > > - Simple Client Mode: > > > server view, it's OK: > > 538909bf conn=1007 fd=32 TLS established tls_ssf=256 ssf=256 > > > > sha512 > ------ > rm previous symlink and ln -s gnutls512_normal.pem sslcertificate.pem ; then > restart openldap > > make a connection: > > gnutls-cli ldap.verry.org -p 636 > Resolving 'ldap.verry.org'... > Connecting to '2a01:e35:2e6d:c800:cafe:deca:0:42:636'... > *** Fatal error: A TLS packet with unexpected length was received. > *** Handshake has failed > GnuTLS error: A TLS packet with unexpected length was received. > > server view: > > TLS: can't accept: Could not negotiate a supported cipher suite.. > 538909f9 connection_read(28): TLS accept failure error=-1 id=1000, closing > 538909f9 connection_closing: readying conn=1000 sd=28 for close > 538909f9 connection_close: conn=1000 sd=28 > 538909f9 daemon: removing 28 > 538909f9 conn=1000 fd=28 closed (TLS negotiation failure) > > > > gnutls > ====== > > gnutls-cli -l|grep SHA512 > MACs: SHA1, MD5, SHA256, SHA384, SHA512, SHA224, UMAC-96, UMAC-128, AEAD > Digests: SHA1, MD5, SHA256, SHA384, SHA512, SHA224 > PK-signatures: SIGN-RSA-SHA1, SIGN-RSA-SHA1, SIGN-RSA-SHA224, SIGN-RSA-SHA256, > SIGN-RSA-SHA384, SIGN-RSA-SHA512, SIGN-RSA-RMD160, SIGN-DSA-SHA1, SIGN-DSA-SHA1, > SIGN-DSA-SHA224, SIGN-DSA-SHA256, SIGN-RSA-MD5, SIGN-RSA-MD5, SIGN-RSA-MD2, > SIGN-ECDSA-SHA1, SIGN-ECDSA-SHA224, SIGN-ECDSA-SHA256, SIGN-ECDSA-SHA384, > SIGN-ECDSA-SHA512 > > I can provide more information as needed to solve this issue > > Regards, > Yann > > > -- -- 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#7867) TLS SHA512
by yann+openldap＠verry.org 31 May '14

31 May '14

Full_Name: Yann Verry Version: 2.4.39 OS: debian/sid URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a01:e35:2e6d:c800:d572:aec:1b42:380c) Hi, I would like (CACert sign class3 now with SHA512) to switch my X509 certificate with a signature algorithm SHA512. When I do this openldap bind on SSL port but was unable to provide SSL connection as you can see in error: 2014-05-31T00:20:46.852821+02:00 peach slapd[23997]: >>> slap_listener(ldaps:///) 2014-05-31T00:20:46.853369+02:00 peach slapd[23997]: connection_get(35): got connid=1068 2014-05-31T00:20:46.853891+02:00 peach slapd[23997]: connection_read(35): checking for input on id=1068 2014-05-31T00:20:46.854526+02:00 peach slapd[23997]: connection_read(35): TLS accept failure error=-1 id=1068, closing 2014-05-31T00:20:46.855071+02:00 peach slapd[23997]: connection_close: conn=1068 sd=35 If I fall back to sha256 it works fine How to reproduce ================ - generate self signed with sha256 and sha512: mkdir -p /etc/ldap/ssl cd !$ # priv certtool --generate-privkey --sec-param normal --outfile mypriv_normal.key # self certtool -s --load-privkey mypriv_normal.key --outfile gnutls512_normal.crt --hash SHA512 certtool -s --load-privkey mypriv_normal.key --outfile gnutls256_normal.crt --hash SHA256 # build PEM cat mypriv_normal.key gnutls512_normal.crt > gnutls512_normal.pem cat mypriv_normal.key gnutls256_normal.crt > gnutls256_normal.pem my cn=config: olcTLSCACertificateFile: /etc/ldap/ssl/sslcertificate.pem olcTLSCertificateFile: /etc/ldap/ssl/sslcertificate.pem olcTLSCertificateKeyFile: /etc/ldap/ssl/sslcertificate.pem now just play with symlink. sha256 ------ ln -s gnutls256_normal.pem sslcertificate.pem ; then restart openldap make a client connection: gnutls-cli ldap.verry.org -p 636 Resolving 'ldap.verry.org'... Connecting to '2a01:e35:2e6d:c800:cafe:deca:0:42:636'... - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - subject `CN=ldap.verry.org', issuer `CN=ldap.verry.org', RSA key 2432 bits, signed using RSA-SHA256, activated `2014-05-31 08:26:59 UTC', expires `2024-05-28 08:27:03 UTC', SHA-1 fingerprint `600b2a502289644c075d4b3eaf7b1efd38685687' - The hostname in the certificate matches 'ldap.verry.org'. - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.2 - Key Exchange: RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed - Simple Client Mode: server view, it's OK: 538909bf conn=1007 fd=32 TLS established tls_ssf=256 ssf=256 sha512 ------ rm previous symlink and ln -s gnutls512_normal.pem sslcertificate.pem ; then restart openldap make a connection: gnutls-cli ldap.verry.org -p 636 Resolving 'ldap.verry.org'... Connecting to '2a01:e35:2e6d:c800:cafe:deca:0:42:636'... *** Fatal error: A TLS packet with unexpected length was received. *** Handshake has failed GnuTLS error: A TLS packet with unexpected length was received. server view: TLS: can't accept: Could not negotiate a supported cipher suite.. 538909f9 connection_read(28): TLS accept failure error=-1 id=1000, closing 538909f9 connection_closing: readying conn=1000 sd=28 for close 538909f9 connection_close: conn=1000 sd=28 538909f9 daemon: removing 28 538909f9 conn=1000 fd=28 closed (TLS negotiation failure) gnutls ====== gnutls-cli -l|grep SHA512 MACs: SHA1, MD5, SHA256, SHA384, SHA512, SHA224, UMAC-96, UMAC-128, AEAD Digests: SHA1, MD5, SHA256, SHA384, SHA512, SHA224 PK-signatures: SIGN-RSA-SHA1, SIGN-RSA-SHA1, SIGN-RSA-SHA224, SIGN-RSA-SHA256, SIGN-RSA-SHA384, SIGN-RSA-SHA512, SIGN-RSA-RMD160, SIGN-DSA-SHA1, SIGN-DSA-SHA1, SIGN-DSA-SHA224, SIGN-DSA-SHA256, SIGN-RSA-MD5, SIGN-RSA-MD5, SIGN-RSA-MD2, SIGN-ECDSA-SHA1, SIGN-ECDSA-SHA224, SIGN-ECDSA-SHA256, SIGN-ECDSA-SHA384, SIGN-ECDSA-SHA512 I can provide more information as needed to solve this issue Regards, Yann

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