openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#6467) syncrepl enhancements
by hyc＠OpenLDAP.org 02 Feb '10

02 Feb '10

Full_Name: Howard Chu Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.212) Submitted by: hyc Syncrepl refreshes can be very expensive without a sessionlog, and the syncprov sessionlog is inadequate because it's in-memory only, and doesn't survive a restart. Syncprov should be extended to take advantage of the accesslog overlay if it is available.

1 0

Re: (ITS#6464) Buffer overflow
by csdr＠lthd.com 01 Feb '10

01 Feb '10

Sorry. I hope this helps: http://lthd.com/slapd.out On 01/31/2010 01:05 AM, Howard Chu wrote: > csdr(a)lthd.com wrote: >> 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. >> > Please provide a stack trace from this crash. Be sure to compile with > debug symbols enabled and no optimization, otherwise we won't be able > to track anything down. >

1 0

Re: (ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by masarati＠aero.polimi.it 01 Feb '10

01 Feb '10

hyc(a)symas.com wrote: >> BTW, what do you mean by "needs some thought" (in the ticket notes)? > > I hadn't decided yet if slapd should log a warning for this or not. A warning, to be useful, should allow to clearly identify the broken piece of data. Where the issue is identified, there's no way to find out the DN of the entry that contains the datum. All you could use is the certificate's content (e.g. issuer DN and so); not sure how helpful it would be. p.

1 0

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

01 Feb '10

Erwann Abalea wrote: > Hodie III Kal. Feb. MMX, Howard Chu scripsit: (Sorry, just had to laugh, using a ~3000 year old language in email...) >> erwann.abalea(a)keynectis.com wrote: >> 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. > > I didn't know that LDAP was designed to conform to a specific edition > of the standard. Isn't that strange? After all, it should also refuse > to handle X.509v2 CRLs, and X.509v3 certificates, which appear for the > first time in the 1997 edition. > Anyway, I hadn't thought about looking at older revisions of the X.509 > standard. You're right, my 1997 edition doesn't say anything about > this, and my 2000 edition (a french version) has the same text as the > 2005 one. See RFC4510, section 2. Yes, it's certainly an inconsistency in the LDAP spec, that RFC4513 requires use of subjectAltNames which clearly require X.509v3 certs but the only normative references to the necessary edition of X.509 is outside the core specification. (Looking again I see that RFC4523 references X.509(2000) so it appears that some portions of newer X.500 editions are being incorporated, piecemeal...) > Anyway, thank you again. I'll test the head version and will come back > later. > BTW, what do you mean by "needs some thought" (in the ticket notes)? I hadn't decided yet if slapd should log a warning for this or not. -- -- 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#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by erwann.abalea＠keynectis.com 01 Feb '10

01 Feb '10

Hodie III Kal. Feb. MMX, Howard Chu scripsit: > erwann.abalea(a)keynectis.com wrote: > >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): Thank you for having corrected it. > >>>> > 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. > <<<< That's what I meant to write when I wrote that the element SHOULD be omitted. X.509 doesn't prevent such an empty sequence, it only strongly recommends to avoid it. A strong recommendation in ISO terminology is as a SHOULD in RFC2119 meaning. You're right, here. > 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. I didn't know that LDAP was designed to conform to a specific edition of the standard. Isn't that strange? After all, it should also refuse to handle X.509v2 CRLs, and X.509v3 certificates, which appear for the first time in the 1997 edition. Anyway, I hadn't thought about looking at older revisions of the X.509 standard. You're right, my 1997 edition doesn't say anything about this, and my 2000 edition (a french version) has the same text as the 2005 one. > We may consider logging a warning for this case. What software > generated this CRL? It seems to be defective... At first, I also thought it was defective. But after all, the standard doesn't say that this revokedCertificates element MUST be eliminated when no certificate is revoked (I use RFC2119 terminology here, but you certainly got it). I certainly will produce a warning to the software vendor, though. In general, I tend to follow "SHOULD" rules. I don't know what software produced this CRL (yet), I only know who uses it (one of our customers). I'll get in touch with them for that. In the same time, I'll check that we correctly do our job (we're also a PKI software vendor). Anyway, thank you again. I'll test the head version and will come back later. BTW, what do you mean by "needs some thought" (in the ticket notes)? -- Erwann ABALEA <erwann.abalea(a)keynectis.com> ----- "Common sense is the collection of prejudices acquired by age 18." - Albert Einstein

1 0

Re: (ITS#6464) Buffer overflow
by hyc＠symas.com 30 Jan '10

30 Jan '10

csdr(a)lthd.com wrote: > 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. > Please provide a stack trace from this crash. Be sure to compile with debug symbols enabled and no optimization, otherwise we won't be able to track anything down. -- -- 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#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

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