openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by hyc＠symas.com 30 Jan '10

30 Jan '10

erwann.abalea(a)keynectis.com wrote: > Full_Name: Erwann Abalea > Version: 2.4.17 > OS: Debian/testing > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.167.155.1) > > > As indicated in the subject, certificateListValidate() doesn't validate some > valid CRLs. Those CRLs are valid from X.509 point of view, but do not conform to > RFC5280 (which is only a profile of the standard). > > When no certificate is revoked, the revokedCertificate element SHOULD be > omitted, instead of being included as an empty SEQUENCE OF SEQUENCE. RFC5280 has > changed the SHOULD into a MUST, but I don't think this is checked by the > function. I think it only skips over the next element (in my case, the > crlExtensions). Thanks for the report. The code in CVS HEAD has been patched to silently accept this case. However, it's worth pointing out that even in X.509(2005): >>>> If none of the certificates covered by this CRL have been revoked, it is strongly recommended that revokedCertificates parameter be omitted from the CRL, rather than being included with an empty SEQUENCE. <<<< Also note that, technically, LDAP is defined to conform to the 1993 edition of the X.500 specs, and X.509(1993) makes no such allowance here. We may consider logging a warning for this case. What software generated this CRL? It seems to be defective... > Here's a real-life CRL: > certificateRevocationList;binary:: MIIBPTCBpwIBATANBgkqhkiG9w0BAQUFADAkMQswCQY > DVQQGEwJGUjEVMBMGA1UEChMMR0lQLUNQUy1URVNUFw0wOTA5MTcxMDEyNTdaFw0xMDA2MjQxMDEy > NTdaMACgTTBLMB8GA1UdIwQYMBaAFOH6F/gUI8Xen3tJVqLlQphs5EovMAoGA1UdFAQDAgECMBwGA > 1UdEgQVMBOBEWFjLWdpcEBnaXAtY3BzLmZyMA0GCSqGSIb3DQEBBQUAA4GBAByCwHi4fZG95ScpLO > 2HW+5I1zeodXlbTOCgnbLVLLz0WjXXZpa5ecn2aHpqrc5L70UIKBhrk/LJ8+y03UBtx6z1gdGNL3u > +rbVQcMgbKJ5AbLojfyWeS4d6n8TZBlM0Wd5eJ6AlwPKRvNV//QH3vjMPVWeD2XYtwQhBYqEGJrvn > > And a real-life deltaCRL: > deltaRevocationList;binary:: MIIBTjCBuAIBATANBgkqhkiG9w0BAQUFADAkMQswCQYDVQQGE > wJGUjEVMBMGA1UEChMMR0lQLUNQUy1URVNUFw0wODEyMjQwMzAwMjNaFw0wODEyMzAwMzAwMjNaMA > CgXjBcMB8GA1UdIwQYMBaAFOH6F/gUI8Xen3tJVqLlQphs5EovMAsGA1UdFAQEAgIKAjAOBgNVHRs > BAf8EBAICCgEwHAYDVR0SBBUwE4ERYWMtZ2lwQGdpcC1jcHMuZnIwDQYJKoZIhvcNAQEFBQADgYEA > gEk/dBR5Vz+RtfBp4hpPaSX1aXFAzx6pZCSBaQ4dFfbXV9HkbPM/2dh32HRDueyhJnXmfn/m5Q9Vo > syEzF1MQEDYZV0A5Liu8oiZtY9gfe522pz7+oehZdOyzkLx6nUw6uLLTL62q8lRbDsNbZNsu22sz7 > dAucnBo63ksdGgdFQ= > > You'll see empty SEQUENCEs. Bug probably around line 314 of file schema_init.c, > but I don't know openldap internals enough to correct it by myself. > > Thanks. -- -- 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#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by erwann.abalea＠keynectis.com 29 Jan '10

29 Jan '10

Full_Name: Erwann Abalea Version: 2.4.17 OS: Debian/testing URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.167.155.1) As indicated in the subject, certificateListValidate() doesn't validate some valid CRLs. Those CRLs are valid from X.509 point of view, but do not conform to RFC5280 (which is only a profile of the standard). When no certificate is revoked, the revokedCertificate element SHOULD be omitted, instead of being included as an empty SEQUENCE OF SEQUENCE. RFC5280 has changed the SHOULD into a MUST, but I don't think this is checked by the function. I think it only skips over the next element (in my case, the crlExtensions). Here's a real-life CRL: certificateRevocationList;binary:: MIIBPTCBpwIBATANBgkqhkiG9w0BAQUFADAkMQswCQY DVQQGEwJGUjEVMBMGA1UEChMMR0lQLUNQUy1URVNUFw0wOTA5MTcxMDEyNTdaFw0xMDA2MjQxMDEy NTdaMACgTTBLMB8GA1UdIwQYMBaAFOH6F/gUI8Xen3tJVqLlQphs5EovMAoGA1UdFAQDAgECMBwGA 1UdEgQVMBOBEWFjLWdpcEBnaXAtY3BzLmZyMA0GCSqGSIb3DQEBBQUAA4GBAByCwHi4fZG95ScpLO 2HW+5I1zeodXlbTOCgnbLVLLz0WjXXZpa5ecn2aHpqrc5L70UIKBhrk/LJ8+y03UBtx6z1gdGNL3u +rbVQcMgbKJ5AbLojfyWeS4d6n8TZBlM0Wd5eJ6AlwPKRvNV//QH3vjMPVWeD2XYtwQhBYqEGJrvn And a real-life deltaCRL: deltaRevocationList;binary:: MIIBTjCBuAIBATANBgkqhkiG9w0BAQUFADAkMQswCQYDVQQGE wJGUjEVMBMGA1UEChMMR0lQLUNQUy1URVNUFw0wODEyMjQwMzAwMjNaFw0wODEyMzAwMzAwMjNaMA CgXjBcMB8GA1UdIwQYMBaAFOH6F/gUI8Xen3tJVqLlQphs5EovMAsGA1UdFAQEAgIKAjAOBgNVHRs BAf8EBAICCgEwHAYDVR0SBBUwE4ERYWMtZ2lwQGdpcC1jcHMuZnIwDQYJKoZIhvcNAQEFBQADgYEA gEk/dBR5Vz+RtfBp4hpPaSX1aXFAzx6pZCSBaQ4dFfbXV9HkbPM/2dh32HRDueyhJnXmfn/m5Q9Vo syEzF1MQEDYZV0A5Liu8oiZtY9gfe522pz7+oehZdOyzkLx6nUw6uLLTL62q8lRbDsNbZNsu22sz7 dAucnBo63ksdGgdFQ= You'll see empty SEQUENCEs. Bug probably around line 314 of file schema_init.c, but I don't know openldap internals enough to correct it by myself. Thanks.

1 0

(ITS#6465) startup error after converting to slapd-config
by gerard.ranke＠kmt.hku.nl 29 Jan '10

29 Jan '10

Full_Name: Gerard Ranke Version: 2.4.21 OS: IRIX 6.5.30 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.87.216.230) We run openLDAP 2.4.21 on one master plus 7 slaves. Some time ago ( I believe we were on 2.4.19 at the time ), I converted one of the slaves to slapd-config from slapd.conf to get myself acquainted with it, and that went without problems. Now, if I try the conversion with slaptest -f slapd.conf -F slapd.d, the conversion works ok, but slapd won't start, and gives this error: Jan 18 15:30:20 7E:example-slave slapd[1741992]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb Jan 18 15:30:20 7U:example-slave slapd[1741992]: olcSyncrepl: value #0: <olcSyncrepl> invalid URL Jan 18 15:30:20 7U:example-slave slapd[1741992]: config error processing olcDatabase={1}hdb,cn=config: <olcSyncrepl> invalid URL Jan 18 15:30:20 7U:example-slave slapd[1741992]: slapd stopped. Jan 18 15:30:20 7U:example-slave slapd[1741992]: connections_destroy: nothing to destroy. I noticed that the olcSyncrepl in olcDatabase={1}hdb,cn=config changed from: olcSyncrepl: rid=001 provider=ldap://masterldap.example.com:389 bindmethod=simple timeout =0 network-timeout=0 binddn="cn=syncuser,dc=example,dc=com" credentials="xxxxxxxxx " starttls=critical filter="(objectClass=*)" searchbase="dc=example,dc=com" scope= sub attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 5 10 +" for the older openldap version, to: olcSyncrepl: rid=001 provider=ldap://masterldap.example.com:389 uri="" bindmethod=simple timeout=0 network-timeout=0 binddn="cn=syncuser,dc=example,dc=com" credentials="xxxxxxxxx" starttls=critical tls_cert="/usr/ssl/certs/examplewildcard.cert " tls_key="/usr/ssl/certs/examplewildcard.key" tls_cacert="/usr /ssl/certs/cacert_root.crt" tls_reqcert=demand tls_crlcheck=none filter="(obj ectClass=*)" searchbase="dc=example,dc=com" scope=sub attrs="*,+" schemachecking=o ff type=refreshAndPersist retry="5 5 10 +" for 2.4.21. Notice the ' uri="" ' in the last version. Fortunately, if I remove the empty uri assignment from the ldif file, slapd starts normally. I also noticed the slaves which I converted earlier ( so which had the first olcSyncrepl 'format' above ) didn't replicate properly ( contextcsn also lagging behind ). I shut down slapd on these machines, cleaned out slapd.d, converted again, removed the 'uri=""' and restarted. After that, the replication caught up by itself. Thanks for your attention for this!

1 0

(ITS#6464) Buffer overflow
by csdr＠lthd.com 28 Jan '10

28 Jan '10

Full_Name: Chis-Serban Dinu-Razvan Version: 2.4.21 OS: Fedora 12 URL: http://lthd.com/out1.txt Submission from: (NULL) (193.231.233.40) I have a master ldap server running openldap 2.4.21 and 3 replicas running 2.4.15 and 2.4.19 and I when I try to delete/rename an object, the master dies with an buffer overflow error. I mention that before the master was 2.4.15 and the replica running 2.4.19 died. I have updated the master to 2.4.19 and it start dyeing. Then I upgraded it to 2.4.21 an it still dies. It dies even if the syncprov is off.

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 27 Jan '10

27 Jan '10

--0-1999948331-1264610847=:54320 Content-Type: text/plain; charset=us-ascii We found out that this call : ldap_msgfree(res); does not get executed because the LDAPMessage is NULL (res is null) in case the timeout is on the client side. There is any other way to clean it? --0-1999948331-1264610847=:54320 Content-Type: text/html; charset=us-ascii <table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">We found out that this call :<br><br>ldap_msgfree(res);<br><br>does not get executed because the LDAPMessage is NULL (res is null) in case the timeout is on the client side.<br><br>There is any other way to clean it?<br></td></tr></table><br> --0-1999948331-1264610847=:54320--

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 27 Jan '10

27 Jan '10

--0-1407467353-1264601923=:2093 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =A0 A similar issue was found in Netscape SDK :=A0 http://www.mail-archive.= com/mozilla-directory(a)mozilla.org/msg01734.html =0A=0A=0A --0-1407467353-1264601923=:2093 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"= top" style=3D"font: inherit;">  A similar issue was found in Netscape = SDK :  http://www.mail-archive.com/mozilla-directory@mozilla.org/msg01= 734.html<br><br></td></tr></table><br>=0A=0A --0-1407467353-1264601923=:2093--

1 0

memberof overlay
by Daniel Gomes 27 Jan '10

27 Jan '10

Dear list members, I have been trying to get the memberof overlay to work properly on slapd 2.4.19 on an Ubuntu hardy (8.04.3). After realizing (which took a while hehe) that installing OpenLDAP via apt-get wouldn't allow me to enable modules/overlays, I downloaded the source and built it manually with: ./configure --enable-overlays --enable-accesslog --enable-auditlog --enable-collect --enable-constraint --enable-dds --enable-deref --enable-dyngroup --enable-dynlist --enable-memberof --enable-ppolicy --enable-proxycache --enable-refint --enable-retcode --enable-rwm --enable-seqmod --enable-syncprov --enable-translucent --enable-unique --enable-valsort --enable-modules --with-tls (I wanted to be on the safe side so I kinda enabled everything) The server is now set up and running (with TLS and all, but I guess that's not important here). To activate the wanted overlay, I have (on my slapd.conf): modulepath /usr/local/etc/openldap/overlays/ moduleload memberof.la overlay memberof (the path is correct and I have checked the logs to make sure he was paying attention to those fields). Anyway, I starting making some experiences, and at first it seemed to be working fine. But some test cases later, the memberOf value started being incorrect, when comparing to the member attribute of the groups. Here's how to reproduce my scenario (I just tried it again, with a new database, base DN being dc=ipfn,dc=ist,dc=utl,dc=pt): First, run init.ldif (attached), which creates the usual groups and people OU's, creates 2 users followed by 2 group with one user per group. So far so good, if I make a ldapsearch based on ou=people (...) and ask for the memberOf attribute, I get: dn: ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=Daniel Gomes,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt memberOf: cn=admin,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=John Smith,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt memberOf: cn=users,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt ---------------------------------------- Next, I run modify.ldif (also attached) which changes the member attribute of the admin group from "cn=Daniel Gomes (...)" to "cn=John Smith (...)". We can then see that: dn: ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt objectClass: organizationalUnit ou: groups dn: cn=admin,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt objectClass: groupOfNames cn: admin description: For administrators member: cn=John Smith,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=users,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt objectClass: groupOfNames cn: users description: For users member: cn=John Smith,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt ---------------------------------------------- Meaning, the group was successfully modified, but the previous query returns the same value: dn: ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=Daniel Gomes,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt memberOf: cn=admin,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=John Smith,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt memberOf: cn=users,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt ----------------------------------------- This seems to happen only when deleting users from groups. I have tried with and without the refint overlay, if that matters for anything. Anyway, I do not see anything I can be doing wrong, so it does seem to be a bug. If I could get some info on this, I would appreciate it! Cheers, -- Daniel Gomes (SysAdmin) dgomes(a)ipfn.ist.utl.pt Ext. 3487 - 218419487 Instituto de Plasmas e usão Nuclear Instituto Superior Técnico - UTL Av. Rovisco Pais - 1049-001 Lisboa - Portugal

1 0

Re: (ITS#6462) DNS SRV records: ldaps ???
by quanah＠zimbra.com 26 Jan '10

26 Jan '10

--On Wednesday, January 27, 2010 1:28 AM +0000 jochen(a)keutel.de wrote: > Full_Name: Jochen Keutel > Version: 2.4.21 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > protocol is either "ldap" oder "ldaps". LDAPS is not a defined protocol. I would suggest using LDAP with startTLS, which is RFC Defined. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6463) dnssrv_back_referrals: ldaps not handled, search base gone
by jochen＠keutel.de 26 Jan '10

26 Jan '10

Full_Name: Jochen Keutel Version: 2.4.21 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.159.206.14) dnssrv_back_referrals() always returns ldap URLs - even when the original request was a ldaps query. Additionally only protocol and hostname are put into the URL - the search base doesn't appear any more. Problematic code: url.bv_len = STRLENOF( "ldap://" ) + strlen( hosts[i] ); url.bv_val = ch_malloc( url.bv_len + 1 ); strcpy( url.bv_val, "ldap://" ); strcpy( &url.bv_val[STRLENOF( "ldap://" )], hosts[i] ); I'm not sure whether you want me to deliver a complete patch or not ... Thanks to my colleague Manuel Gaupp for detecting this problem. Best regards, Jochen.

1 0

(ITS#6462) DNS SRV records: ldaps ???
by jochen＠keutel.de 26 Jan '10

26 Jan '10

Full_Name: Jochen Keutel Version: 2.4.21 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.159.206.14) The code for detecting LDAP servers via DNS SRV records seems to handle only ldap URLs - not ldaps URLs. Esp.: If you access an OpenLDAP server with ldaps://host1/..., then the DNS SRV code returns a URL like ldap://host2/... . So the LDAP server chains the original ldaps request as a LDAP query without TLS. This gets problematic when the (company / project) requirements clearly state that only ldaps has to be used ... The problematic code seems to be in libraries/libldap/dnssrv.c, function ldap_domain2hostlist(): request = LDAP_MALLOC(strlen(domain) + sizeof("_ldap._tcp.")); ... sprintf(request, "_ldap._tcp.%s", domain); So always "_ldap._tcp" is used (hard coded) - not "ldaps._tcp" in case of ldaps in the original query. I'd suggest to introduce a third parameter to that function: int ldap_domain2hostlist( LDAP_CONST char *protocol, LDAP_CONST char *domain, char **list ) protocol is either "ldap" oder "ldaps". The code calling this function (slapd/back-dnssrv/search.c and referral.c) has to be adjusted as well. I'm not sure whether you want me to deliver a complete patch or not ... Thanks to my colleague Manuel Gaupp for detecting this problem. Best regards, Jochen.

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