openldap-bugs

openldap-bugs@openldap.org

1 participants
21517 discussions

Re: (ITS#5998) jitterbug
by michael＠stroeder.com 05 Mar '09

05 Mar '09

Kurt(a)OpenLDAP.org wrote: > On Mar 4, 2009, at 6:53 PM, hyc(a)OpenLDAP.org wrote: > >> Full_Name: Howard Chu >> Version: 1.0 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (76.91.220.157) >> Submitted by: hyc >> >> >> Where are these resubmits coming from? > > My guess: the user. Yes, it happened also to me one time. I think there was a change in the UI which makes it more easy to submit the input form twice. Ciao, Michael.

1 0

Re: (ITS#5985) replication lockout with syncrepl
by hyc＠symas.com 05 Mar '09

05 Mar '09

hyc(a)symas.com wrote: > Fixing this issue would require a complete redesign of the psearch queue > handling. Instead of queuing up a separate response per psearch, there should > be a single queue of responses, and the qplayer should iterate thru to match a > response to each of the active psearches. That would guarantee that all > replicas receive a given change before any of them receives the next change. > This would also help with the ordering issues discussed recently on -technical > and -devel. Except that this would also force all replication to run at the speed of the slowest consumer... > I suspect this is too big a change to target the next (.16) release, since > we're focusing on re-stabilizing the code right now. The new code in HEAD is actually simpler now, it just pushes ops into the thread pool. Please test... -- -- 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#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by ando＠sys-net.it 05 Mar '09

05 Mar '09

mariusp44(a)gmail.com wrote: > sorry, if I was misunderstood. I am not asking to do my legwork. Just > trying to understand what is going wrong. Sorry, if it seemed that way. > > I installed Sun Studio 12 (latest) and the problem is the same. I don't > think Sun Studio is not working compiler. Just looks very unlikely. IT > compiles everything without single problem. both 32 and 64 bit memory > models. > > Perhaps I was not entirely clear. Weird thing is that it is only not > working when changing password using ldappasswd and hash is set to SMD5 > SSHA or CRYPT. If I manually change the password setting userPassword > after generating it with slappasswd using say SSHA, it works fine. I > mean user can bind using password that is stored in SSHA or SMD5. That > tells me that slapd can still do encryption properly and check against > hashes in question. At some point it needs to generate a hash and does > it properly. Only when slapd is asked to change a password with > ldappasswd it is unable to generate proper hash. Unless process is > entirely different when changing password and authorizing against password. > I am not insisting it is a bug in slapd code. But I am running out of > ideas what else could be wrong and was just hoping that somebody else is > using openldap on the same architecture and perhaps experienced > something similar. Since no one else is seeing the problem, I already recommended that you step in the (non-optimized) code with a debugger and see why this happens. The right place to start is slap_passwd_hash_type(), whose failure is setting the error message you see. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 04 Mar '09

04 Mar '09

sorry, if I was misunderstood. I am not asking to do my legwork. Just trying to understand what is going wrong. Sorry, if it seemed that way. I installed Sun Studio 12 (latest) and the problem is the same. I don't think Sun Studio is not working compiler. Just looks very unlikely. IT compiles everything without single problem. both 32 and 64 bit memory models. Perhaps I was not entirely clear. Weird thing is that it is only not working when changing password using ldappasswd and hash is set to SMD5 SSHA or CRYPT. If I manually change the password setting userPassword after generating it with slappasswd using say SSHA, it works fine. I mean user can bind using password that is stored in SSHA or SMD5. That tells me that slapd can still do encryption properly and check against hashes in question. At some point it needs to generate a hash and does it properly. Only when slapd is asked to change a password with ldappasswd it is unable to generate proper hash. Unless process is entirely different when changing password and authorizing against password. I am not insisting it is a bug in slapd code. But I am running out of ideas what else could be wrong and was just hoping that somebody else is using openldap on the same architecture and perhaps experienced something similar. /M. hyc(a)symas.com wrote: > mariusp44(a)gmail.com wrote: >> as I have pointed out in earlier post not only it doesn't work when I >> compile it myself but also the one that was downloaded form >> sunfreeware.com. It is not possible to tell what version of gcc was >> used to compile openldap that is distributed but explanation that it >> doesn't work because of compiler bug seems to me highly unlikely. >> Unless you can specifically point to which bug in gcc on SPARC >> contributes to this erratic behaviour of openldap. > > It's not our responsibility to do your legwork for you. You can easily email > the maintainers at sunfreeware.com and ask them. Since they currently host gcc > 3.4.6 on their site it's a safe bet they're still using gcc 3.4.x overall. > > Fyi, I have just now built the 2.4.15 source using gcc 4.0.3 on SPARC/Solaris > and all of the hash mechanisms work fine. I don't have a gcc 3.x build handy > on my system, nor do I see any reason to install a known-bad compiler just to > further demonstrate what has already been plainly documented by other folks. >> Either way, thanks for comments. >> >> /M. >> >> On Mon, Mar 2, 2009 at 5:56 PM,<hyc(a)symas.com> wrote: >>> ando(a)sys-net.it wrote: >>>> mariusp44(a)gmail.com wrote: >>>>> I have just compiled and tested 2.4.15 and result is same: cleartext, >>>>> md5 and sha works, smd5, ssha and crypt doesn't. >>>>> >>>>> Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. >>>> I have no chance to test on that arch. You should figure our why those >>>> hashes are not supported. Did you enable crypt (--enable-crypt)? >>> gcc 3.4.3 was released November 4 2004 http://gcc.gnu.org/gcc-3.4/ >>> >>> and is known to have many bugs. It's also already known that old gcc releases >>> have other problems on Sparc. (E.g. ITS#5875.) >>> >>> Please use a working compiler. >>> >>> As a workaround, recompile the offending functions with optimization disabled. >>> That usually helps in cases like this. >>> >>> There is no bug in OpenLDAP Software here, this ITS will be closed. >>> >>> -- >>> -- 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#5991) slapd+gnutls doesn't send all of the CA certs available in the certficate chain while slapd+openssl does
by hyc＠symas.com 04 Mar '09

04 Mar '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> mathias.gug(a)canonical.com wrote: >>> Full_Name: Mathias Gug >>> Version: 2.4.15 >>> OS: Ubuntu Linux (Jaunty - 9.04) >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (64.56.226.136) >>> >>> >>> slapd+gnutls doesn't send all the certificates in the chain while slapd+openssl >>> does. >>> >>> openldap version: 2.4.15 >>> gnutls version: 2.4.2 >>> openssl version: 0.9.8g > > I'm unable to reproduce this using GnuTLS 2.6. Why are you using 2.4? > Hm, I may have been testing the wrong code before, I see it now. A fix is coming in HEAD. -- -- 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#5991) slapd+gnutls doesn't send all of the CA certs available in the certficate chain while slapd+openssl does
by hyc＠symas.com 04 Mar '09

04 Mar '09

hyc(a)symas.com wrote: > mathias.gug(a)canonical.com wrote: >> Full_Name: Mathias Gug >> Version: 2.4.15 >> OS: Ubuntu Linux (Jaunty - 9.04) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (64.56.226.136) >> >> >> slapd+gnutls doesn't send all the certificates in the chain while slapd+openssl >> does. >> >> openldap version: 2.4.15 >> gnutls version: 2.4.2 >> openssl version: 0.9.8g I'm unable to reproduce this using GnuTLS 2.6. Why are you using 2.4? -- -- 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#5991) slapd+gnutls doesn't send all of the CA certs available in the certficate chain while slapd+openssl does
by hyc＠symas.com 04 Mar '09

04 Mar '09

mathias.gug(a)canonical.com wrote: > Full_Name: Mathias Gug > Version: 2.4.15 > OS: Ubuntu Linux (Jaunty - 9.04) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.56.226.136) > > > slapd+gnutls doesn't send all the certificates in the chain while slapd+openssl > does. > > openldap version: 2.4.15 > gnutls version: 2.4.2 > openssl version: 0.9.8g > > Here are two systems running slapd 2.4.15 - one compiled with gnutls > (t-slapd-gnutls), the other with openssl (t-slapd-openssl). This appears to be a logical disconnect between the GnuTLS and OpenSSL APIs; the OpenLDAP docs were written for OpenSSL... The way we use the OpenSSL library, it's assumed that only a single cert and key are present in the configured certfile and keyfile, and all of the relevant CAs for that cert are present in the CA file/path. In the GnuTLS library, the library expects the entire cert chain to be present in the certfile. I think it's clear from this message http://groups.google.com/group/linux.debian.bugs.dist/msg/8fec96a62571d6e9 that this is a weakness in the GnuTLS API, one that prevents it from distinguishing between CA certs and end-entity certs, and thus the reason the whole V1 trust problem arose in the first place. As an immediate workaround, you can simply copy the appropriate CA certs into your server cert file. In the meantime it looks like we'll just have to use gnutls_certificate_set_x509_key() to address this. > mathiaz@t-slapd-gnutls:~$ gnutls-cli --x509cafile allca.pem --print-cert -p 636 > t-slapd-gnutls. > Processed 2 CA certificate(s). > Resolving 't-slapd-gnutls.'... > Connecting to '172.19.42.87:636'... > - Certificate type: X.509 > - Got a certificate list of 1 certificates. > > - Certificate[0] info: > > -----BEGIN CERTIFICATE----- > MIICyTCCAjKgAwIBAgIBBTANBgkqhkiG9w0BAQUFADBIMQswCQYDVQQGEwJDQTEL > MAkGA1UECBMCUUMxEDAOBgNVBAoTB01hdGhpYXoxGjAYBgNVBAMTEVRFU1QgQ0FW > MSAtIEhBUkRZMB4XDTA5MDMwNDE5NTcxMVoXDTEwMDMwNDE5NTcxMVowRjELMAkG > A1UEBhMCQ0ExCzAJBgNVBAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRgwFgYDVQQD > Ew90LXNsYXBkLWdudXRscy4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL5X > ERAGYnqTCJae2FnEB1qT2Hk0sNiD1n+mnyhNDespomTINPLKpZZmqOSlD7x71zuy > DQ/Z6uxgIxOhuUV9VVo2cISi9MmEOYn4qxGq2YIHyra5FJZf6O43qajicDaRRzGz > UA17ap7vDqgig9T4qFvwCllz4EFlcTzxV+N99m1RAgMBAAGjgcQwgcEwCQYDVR0T > BAIwADALBgNVHQ8EBAMCBaAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJh > dGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBSii4L1Po9xGWrMD2oG8VeFuTQtfzBa > BgNVHSMEUzBRoUykSjBIMQswCQYDVQQGEwJDQTELMAkGA1UECBMCUUMxEDAOBgNV > BAoTB01hdGhpYXoxGjAYBgNVBAMTEVRFU1QgQ0FWMSAtIEhBUkRZggEAMA0GCSqG > SIb3DQEBBQUAA4GBAEEQMsEc0VQOt1y8B22xfRewUmwMKk34J80aFkKuG/RQJoBw > TSnlHpqyZFvmOu4JaCJAh6IdTdxfsuDB5vu/5kpNMc3jJX1Ale17l1MuxB6lvcKn > zG3A17BIIZh3aoJcVQgDAQ8Vr/I9z8y51i1Qr37E5HF2GjuuyF+5BJz9lITq > -----END CERTIFICATE----- > > # The hostname in the certificate matches 't-slapd-gnutls.'. > # valid since: Wed Mar 4 14:57:11 EST 2009 > # expires at: Thu Mar 4 14:57:11 EST 2010 > # fingerprint: 72:5A:24:83:6C:5C:3F:0E:80:52:F1:61:CD:C3:0D:31 > # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=t-slapd-gnutls. > # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY > > > - Peer's certificate is trusted > - Version: TLS1.1 > - Key Exchange: RSA > - Cipher: AES-128-CBC > - MAC: SHA1 > - Compression: NULL > - Handshake was completed > > - Simple Client Mode: > > mathiaz@t-slapd-gnutls:~$ gnutls-cli --x509cafile allca.pem --print-cert -p 636 > t-slapd-openssl. > Processed 2 CA certificate(s). > Resolving 't-slapd-openssl.'... > Connecting to '172.19.42.220:636'... > - Certificate type: X.509 > - Got a certificate list of 2 certificates. > > - Certificate[0] info: > > -----BEGIN CERTIFICATE----- > MIIB/jCCAWcCAQcwDQYJKoZIhvcNAQEFBQAwSDELMAkGA1UEBhMCQ0ExCzAJBgNV > BAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRowGAYDVQQDExFURVNUIENBVjEgLSBI > QVJEWTAeFw0wOTAzMDQyMDExMTRaFw0xMDAzMDQyMDExMTRaMEcxCzAJBgNVBAYT > AkNBMQswCQYDVQQIEwJRQzEQMA4GA1UEChMHTWF0aGlhejEZMBcGA1UEAxMQdC1z > bGFwZC1vcGVuc3NsLjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzTEuHfVR > ELoXxSyVTwWrfIIsoKqBfbZYJSGQcTTEtuvxABxX8AoKyc9T+AkhR4wsSmRZGOBz > opH9u0LReaGyhWkUA/XaFF24jkSogi6yDsh478P/ayZjushPLh9LpIeW/2lD9xkh > t5LGW255lXIMGI5+/x8EgiaU1pS5OO9wz/kCAwEAATANBgkqhkiG9w0BAQUFAAOB > gQBlg/lIawsDYFqqNz61BNl2nix4LrIRFxiOA/p14VFkRyuCVHXDjhBtlb13wBZk > wVTDfUdykvy2nlJq8bLQ7OYYdiA4h64HMnLTMyMALKBFiVwyrg/GvF7TsUg3K41K > uFTF0H1bQOmqrJPcIu8r+h3gQLkCRvBLssZaQtA4M4jw4A== > -----END CERTIFICATE----- > > # The hostname in the certificate matches 't-slapd-openssl.'. > # valid since: Wed Mar 4 15:11:14 EST 2009 > # expires at: Thu Mar 4 15:11:14 EST 2010 > # fingerprint: 85:7F:06:0A:EC:3A:9E:6C:78:BC:FC:C3:8F:4D:4B:E9 > # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=t-slapd-openssl. > # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY > > - Certificate[1] info: > > -----BEGIN CERTIFICATE----- > MIIB/zCCAWgCAQAwDQYJKoZIhvcNAQEFBQAwSDELMAkGA1UEBhMCQ0ExCzAJBgNV > BAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRowGAYDVQQDExFURVNUIENBVjEgLSBI > QVJEWTAeFw0wOTAzMDMxODI1NTBaFw0xMjAzMDIxODI1NTBaMEgxCzAJBgNVBAYT > AkNBMQswCQYDVQQIEwJRQzEQMA4GA1UEChMHTWF0aGlhejEaMBgGA1UEAxMRVEVT > VCBDQVYxIC0gSEFSRFkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMZSKqDg > Y5rn4SgJUgnO0IAM2Us/5sQ18mu8gxoDeLkIcHHuiwYHeT4BcOit2hemmOCIEolh > XPKkMD4MVAbafDFtJjhuEgPtWoUuZcOa9gRi3eH+h7QEYhhwnwLewrQGhx4tsfY4 > wR3LIUm/lxkJISy17v3uc5yNLcAlreUrrdJ1AgMBAAEwDQYJKoZIhvcNAQEFBQAD > gYEAAsaBDAMUKofwOZPNNV/9EKglG7O3G5p/i9h8n5C3bXy6E6vWtVxqpWd5qBEt > uMXU1vIIop7FrKornuPWtEy4jKSw12Sv9EXaUJ9rfXQTWh6GpgUmTjlZtOwjABT9 > fAU4M9MdLDTBaZA11NqtdMMPKTwTHXjmv9bKcgOLh1g5WhQ= > -----END CERTIFICATE----- > > # valid since: Tue Mar 3 13:25:50 EST 2009 > # expires at: Fri Mar 2 13:25:50 EST 2012 > # fingerprint: 66:D2:B7:8E:03:DD:BF:24:4D:A1:D8:EA:8E:6F:8B:80 > # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY > # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY > > > - Peer's certificate is trusted > - Version: TLS1.0 > - Key Exchange: RSA > - Cipher: AES-128-CBC > - MAC: SHA1 > - Compression: NULL > - Handshake was completed > > - Simple Client Mode: > > ^C > > -- -- 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#5998) jitterbug
by Kurt＠OpenLDAP.org 04 Mar '09

04 Mar '09

On Mar 4, 2009, at 6:53 PM, hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: 1.0 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > Where are these resubmits coming from? My guess: the user. -- Kurt

1 0

Re: (ITS#5992) libldap with gnutls don't trust V1 CAs.
by hyc＠symas.com 04 Mar '09

04 Mar '09

mathias.gug(a)canonical.com wrote: > Full_Name: Mathias Gug > Version: 2.4.15 > OS: Ubuntu Linux (Jaunty - 9.04) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.56.226.136) > > > Starting with GnuTLS 2.6.3, V1 CA certs are no longer trusted by default when a > CA chain is checked. Thus libldap+gnutls breaks in existing environement when > one of the CA certs uses a V1 certificate. However libldap+openssl still > supports V1 certificates in the CA chain. > > See https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/305264 for more > information. > > Could libldap+gnutls be updated to also support V1 CA certificates to match > features provided by libldap+openssl? Just to be clear, are you requesting that libldap unconditionally call gnutls_certificate_set_verify_flags() with GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT parameter? -- -- 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#5998) jitterbug
by hyc＠OpenLDAP.org 04 Mar '09

04 Mar '09

Full_Name: Howard Chu Version: 1.0 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Where are these resubmits coming from?

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs