- openldap-bugs - openldap.org

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by michael＠stroeder.com 22 Sep '15

22 Sep '15

This is a cryptographically signed message in MIME format. --------------ms030101070905050603070605 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kurt Zeilenga wrote: >=20 >> On Sep 22, 2015, at 10:37 AM, michael(a)stroeder.com wrote: >> >> Kurt Zeilenga wrote: >>> >>>> On Sep 22, 2015, at 12:14 AM, michael(a)stroeder.com wrote: >>>> >>>> Current re24 branch does not accept the following schema description= with double >>>> quote in DESC anymore (which works with 2.4.42) >>> >>> And it shouldn=E2=80=99t, per RFC 4512. >> >> Please be more verbose. >> >> Assuming I'm not mis-reading [1] it allows double quotes in qdstring (= enclosed >> in single quotes). >=20 > You are misreading [1]. the dstring production does not allow the =E2=80= =98 or =E2=80=9C to appear in it. > Instead, \27 is to be used for =E2=80=9C and either \5C or \5c is to be= used for =E2=80=98. You're talking about QQ (single quote ' mentioned in comment as %x27) an= d QS (back-slash mentioned in comment as %x5C). AFAICS the double quote is %x22 and is included in QUTF1. Ciao, Michael. --------------ms030101070905050603070605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDkyMjE4MDIwNFowLwYJKoZIhvcNAQkEMSIEIDB/jT2P8z1vaNnBcy2mGcGUZr6lAPusXEoX FYlfyyEtMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQBSJuATBusD7rXUx/df xf2W9cpi7HJn787NB3MgvRRB/0qXmhNuG2WnSjw/YwAAtixRr3/tK2MHPXMjVphaEm9hiGqp ZWbHiaIvPoBIUwFeM/ehre0x1N8dhpzuK1RQ2OLPij2RKt+ln7XXQOFNXui+v3wug6xAmsuS AueTxwvNo+Pm1syyDwQsnjJpOItDOSEULkEbJ2PVjkcABnNxhKKyZpr79Kofc4mnvImahNsg SufQ+mTd+IX2ILWsXCtU4GJIYpjAuj7UmkXlT4u5LkHlSj9qy6fxS4oZ4keXFWTqEWm/UxzH pLTQu8ILC8CySC8Z4D6g/QPvumDbCbusQkljAAAAAAAA --------------ms030101070905050603070605--

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by kurt＠openldap.org 22 Sep '15

22 Sep '15

Actually I misread it=E2=80=A6 my bad. I was reading QS as =E2=80=9C for some reason=E2=80=A6. must need more = caffeine. Yes, so DESC =E2=80=98=E2=80=9C=E2=80=98 is a legal qdstring. Sorry for the confusion=E2=80=A6 =E2=80=94 Kurt=

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by kurt＠openldap.org 22 Sep '15

22 Sep '15

> On Sep 22, 2015, at 10:37 AM, michael(a)stroeder.com wrote: >=20 > Kurt Zeilenga wrote: >>=20 >>> On Sep 22, 2015, at 12:14 AM, michael(a)stroeder.com wrote: >>>=20 >>> Current re24 branch does not accept the following schema description = with double >>> quote in DESC anymore (which works with 2.4.42) >>=20 >> And it shouldn=E2=80=99t, per RFC 4512. >=20 > Please be more verbose. >=20 > Assuming I'm not mis-reading [1] it allows double quotes in qdstring = (enclosed > in single quotes). You are misreading [1]. the dstring production does not allow the =E2=80=98= or =E2=80=9C to appear in it. Instead, \27 is to be used for =E2=80=9C and either \5C or \5c is to be = used for =E2=80=98. =E2=80=94 Kurt=

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by michael＠stroeder.com 22 Sep '15

22 Sep '15

Kurt Zeilenga wrote: > >> On Sep 22, 2015, at 12:14 AM, michael(a)stroeder.com wrote: >> >> Current re24 branch does not accept the following schema description with double >> quote in DESC anymore (which works with 2.4.42) > > And it shouldn’t, per RFC 4512. Please be more verbose. Assuming I'm not mis-reading [1] it allows double quotes in qdstring (enclosed in single quotes). [1] https://tools.ietf.org/html/rfc4512#section-4.1 Note that this is not a schema file I've created and which I could change. This is the CIM schema provided as is since years. Ciao, Michael.

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by kurt＠openldap.org 22 Sep '15

22 Sep '15

--Apple-Mail=_EF88B354-9156-4D3C-9559-63AB3F05C465 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 22, 2015, at 12:14 AM, michael(a)stroeder.com wrote: >=20 > Current re24 branch does not accept the following schema description = with double > quote in DESC anymore (which works with 2.4.42) And it shouldn=E2=80=99t, per RFC 4512. =E2=80=94 Kurt= --Apple-Mail=_EF88B354-9156-4D3C-9559-63AB3F05C465 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On Sep 22, 2015, at 12:14 AM, <a = href=3D"mailto:michael@stroeder.com" class=3D"">michael(a)stroeder.com</a> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><span = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = line-height: normal; orphans: auto; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: auto; word-spacing: = 0px; -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">Current re24 branch does not accept the = following schema description with double</span><br style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">quote in DESC anymore (which works with = 2.4.42)</span></div></blockquote></div><div class=3D""><br = class=3D""></div><div class=3D"">And it shouldn=E2=80=99t,  per RFC = 4512.</div><div class=3D""><br class=3D""></div><div class=3D"">=E2=80=94 = Kurt</div></body></html>= --Apple-Mail=_EF88B354-9156-4D3C-9559-63AB3F05C465--

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by geert＠hendrickx.be 22 Sep '15

22 Sep '15

On Mon, Sep 21, 2015 at 12:28:35 -0700, Quanah Gibson-Mount wrote: > The rationale was that manageDSAit means let me operate on the raw data and > disable all side-effects. This is still correct and should remain. For clarity I do agree that a control should exist to bypass uniqueness (and other) constraints. However I think manageDSAit is not the appropriate control by its definition, and also in practice given the fact it's set per default by popular client libs. Relax Rules seems much more appropriate for this use case, as it's intended to temporarily relax database constraints, for administrative use only. > However, an option could be added to the module to disable this control > specifically for this overlay. No, then I would need to change the server config to disable that option each time I'd wish to temporarily bypass the constraint, instead of using another dedicated control for that (which would need no disable option). Geert -- geert.hendrickx.be :: geert(a)hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by michael＠stroeder.com 22 Sep '15

22 Sep '15

This is a cryptographically signed message in MIME format. --------------ms040301090601090607070001 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Maybe a regression caused by fix for ITS#8233? >=20 > I don't consider this a regression, the error message is correct. So you don't consider this to be a bug at all? Questions: Is the attribute type desciption syntactically incorrect? I don't think so because the double quote is correctly enclosed in single= quotes. Isn't it admirable that 2.4.43 will also parse correct attribute type desciptions just like 2.4.42 did? Ciao, Michael. --------------ms040301090601090607070001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDkyMjA4MDkwOVowLwYJKoZIhvcNAQkEMSIEIP8a4Fv1HL/ocxij2rGuMQu/vKyamOnfl72t MbYyldeWMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQAC8Rli/OWS6xnYDqYe REyK9yu1teuld+BgI5gZv71k+RNPelUQFxe/BcoJUAOc9lUoUXZjH/37i2F+9eE7/w2WiasF kf3K/2E2BeNps4hxPniqDSIQYLtixB1RbSaNxEpgtFO8CcDSmJa04fzh3Wj14ec6ivPT0qeE OHmDfXMmcf8WoqEqx5eAZi2/G2Tk8uzIzGVqRtoVxhP6eIesCZjBielYs8KP/v1oEM2CYK9K X5NkyxqdFxhBdCRmKIirl/JNH0nZJqA2oV1e1F2Jo3LxwgPUfS4Kr3VELScoNcW/NP28GNUh f5o0Ak8ZOhQ4pNKJbm1leBzhgztG1AkkQ7MMAAAAAAAA --------------ms040301090601090607070001--

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by hyc＠symas.com 22 Sep '15

22 Sep '15

michael(a)stroeder.com wrote: > Maybe a regression caused by fix for ITS#8233? I don't consider this a regression, the error message is correct. -- -- 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#8251) slapd fails schema parsing with double quotes in DESC
by michael＠stroeder.com 22 Sep '15

22 Sep '15

Maybe a regression caused by fix for ITS#8233?

1 0

(ITS#8251) slapd fails schema parsing with double quotes in DESC
by michael＠stroeder.com 22 Sep '15

22 Sep '15

Full_Name: Michael Str.der Version: RE24 branch OS: openSUSE Linux URL: Submission from: (NULL) (79.223.42.239) Current re24 branch does not accept the following schema description with double quote in DESC anymore (which works with 2.4.42): attributetype ( 1.3.6.1.4.1.412.100.2.2.119 NAME 'dlmNameFormat' DESC 'The System object and its derivatives are Top Level Objects of CIM. They provide the scope for numerous components. Having unique System keys is required. A heuristic can be defined in individual System subclasses to attempt to always generate the same System Name Key. The NameFormat property identifies how the System name was generated, using the subclass" heuristic.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE EQUALITY caseIgnoreMatch ) Starting slapd outputs this message: 5600fed2 /home/michael/ftp/Linux/Networking/LDAP/OpenLDAP/schema/cim_core-2.5.schema: line 136: unterminated quoted string "subclass heuristic.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE EQUALITY caseIgnoreMatch ) "

1 0

Re: (ITS#8250) Allowing transaction to be created in the reset state
by rouzier＠gmail.com 21 Sep '15

21 Sep '15

--047d7bd76db0ae5e3d0520480218 Content-Type: text/plain; charset=UTF-8 Sorry I did not retest the patch with after rebasing. Here is the new patch and diff https://github.com/rouzier/openldap/compare/7e476e4983cfba45cefe793b8bd6e13… https://github.com/rouzier/openldap/compare/7e476e4983cfba45cefe793b8bd6e13… On Sat, Sep 19, 2015 at 2:44 PM, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8250. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8250) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#8250) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=8250 > > Please remember to retain your issue tracking number (ITS#8250) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --047d7bd76db0ae5e3d0520480218 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Sorry I did not retest the patch with after rebasing.= </div><div>Here is the new patch and diff</div><div><br></div><a href=3D"ht= tps://github.com/rouzier/openldap/compare/7e476e4983cfba45cefe793b8bd6e13c4= 86b3989...feature/txn-begin-reset.patch">https://github.com/rouzier/openlda= p/compare/7e476e4983cfba45cefe793b8bd6e13c486b3989...feature/txn-begin-rese= t.patch</a><div><br><div><a href=3D"https://github.com/rouzier/openldap/com= pare/7e476e4983cfba45cefe793b8bd6e13c486b3989...feature/txn-begin-reset.dif= f">https://github.com/rouzier/openldap/compare/7e476e4983cfba45cefe793b8bd6= e13c486b3989...feature/txn-begin-reset.diff</a><br></div></div><div><br></d= iv></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, = Sep 19, 2015 at 2:44 PM, <span dir=3D"ltr"><<a href=3D"mailto:openldap-= its(a)openldap.org" target=3D"_blank">openldap-its(a)openldap.org</a>></span= > wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#8250.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#8250)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org">openldap-its(a)openldap.org</a>?subject=3D(ITS#8250)<br> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D825= 0" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= gi?findid=3D8250</a><br> <br> Please remember to retain your issue tracking number (ITS#8250)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re= l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br></div> --047d7bd76db0ae5e3d0520480218--

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by michael＠stroeder.com 21 Sep '15

21 Sep '15

This is a cryptographically signed message in MIME format. --------------ms070405030901070403010409 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable quanah(a)zimbra.com wrote: > Per discussion with Howard & Halvard, >=20 > The rationale was that manageDSAit means let me operate on the raw data= and=20 > disable all side-effects. This is still correct and should remain.=20 > However, an option could be added to the module to disable this control= =20 > specifically for this overlay. Why not just change to use the Relax Rules Control instead? Especially since it already requires manage privilege. Which use-case would not work anymore when using Relax Rules Control inst= ead of manageDSAit control? Do you expect any unwanted side-effects? IIRC the Relax Rules (formerly known as Manage DIT) control was simply no= t yet invented when Pierangelo implemented this. Ciao, Michael. --------------ms070405030901070403010409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDkyMTIwMTIwN1owLwYJKoZIhvcNAQkEMSIEIJWYu87v6+YtojTp06oj2bLHg2pHOysNOSzM 0ip0IgNgMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQA7H/eMKVLo60pmewMT bVp3c2Ob7GaMp5rmexRvLEYCGyyflE10MgnEO6e24T0BiWTiOj7mNhsrZ+Phys1JDWyOXGZb 6Zfah4FKy7lFu3hSMVQ7e9EqWAys5GhpyRu/LiCbCC2ECzOsLL2fDNFa2UgMoWN4TgnX/nzH UXM4WT8EDUwOyAXBoC+PY5HJj3I8x9+uRKvxA5JMkZXYv7jnjw2fmhvIAvIVrlQ0AgyIIsPK 1SvKdY974crYb8FPv+9Wmqw9LU4u9zLY5B9/RTmCAOon4AUUMZJRhb6oMSTMyslaotFeHa3a X3KauocBWxUpsjvOX+tTD4hyp/yfSotkuRBdAAAAAAAA --------------ms070405030901070403010409--

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by quanah＠zimbra.com 21 Sep '15

21 Sep '15

--On Monday, September 14, 2015 8:38 AM +0000 geert(a)hendrickx.be wrote: > Full_Name: Geert Hendrickx > Version: 2.4.42 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.123.14.2) > > > Currently the ManageDsaIt control allows bypassing attribute uniqueness > constraints as implemented by slapo-unique(5). This seems inappropriate > as the ManageDsaIt control (RFC 3296) is intended for managing referral > objects. Also it is set by default by certain clients (specifically Java > JNDI) which makes uniqueness constraints practically useless with such > clients. > > The newer Relax Rules control (draft-zeilenga-ldap-relax) seems much more > appropriate for this use case, please consider using it instead. The > simple pchch below works for me, but I haven't tested its interaction with > replication. Hi Geert, Per discussion with Howard & Halvard, The rationale was that manageDSAit means let me operate on the raw data and disable all side-effects. This is still correct and should remain. However, an option could be added to the module to disable this control specifically for this overlay. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8250) Allowing transaction to be created in the reset state
by rouzier＠gmail.com 19 Sep '15

19 Sep '15

Full_Name: James Rouzier Version: OS: URL: https://github.com/rouzier/openldap/commit/54f60e7eb699778197fa154953fccfa8… Submission from: (NULL) (70.81.32.80) This patch allows mdb_txn_begin to create a transaction in the reset state. So instead of doing this. mdb_txn_begin(env, NULL, MDB_READONLY,&txn); mdb_txn_reset(txn); You now can just do this. mdb_txn_begin(env, NULL, MDB_READONLY| MDB_TXNRESET,&txn); You can view the patch here https://github.com/rouzier/openldap/commit/54f60e7eb699778197fa154953fccfa8… The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by James Rouzier <rouzier(a)gmail.com>. I have not assigned rights and/or interest in this work to any party.

1 0

(ITS#8249) add search response to back-null
by hyc＠openldap.org 17 Sep '15

17 Sep '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.251.255.12) Submitted by: hyc Sometimes we need a simple backend like back-null, but which returns at least 1 entry on search requests.

1 0

(ITS#8248) misleading information in manpage about the use of the logfile option
by steffen.hofmann-credner＠bsi.bund.de 17 Sep '15

17 Sep '15

Full_Name: Steffen Hofmann Version: 2.4.42 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a01:198:5a1:200:10ea:bdac:f2f:c3b8) Misleading information in slapd.conf: an option _logfile_ is described in slapd.conf: "Specify a file for recording debug log messages. [...]" unfortunately it is not clear, what are "debug log messages". Obviously it is not " debugging statements and operation statistics" which can be controlled by the loglevel option. To be honest, I have no clue what the option is for. The only result I got in using this, what a new, empty log file. My, and (by google a few other, too) expected that the logfile option specify the file for the debugging statements.

1 0

(ITS#8247) ru_RU.UTF-8 search problem
by oleg.a.smirnov＠gmail.com 17 Sep '15

17 Sep '15

Full_Name: Oleg Smirnov Version: 2.4.42 OS: linux ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.147.131.107) When searching for Russian words confused Tupper And tolower functions: See to end of the select, russian word wrote in low case: "upper(...) like '%low case%'" 55f9ebc5 Constructed query: SELECT DISTINCT ldap_entries.id,ldapx_persons.id,text('inetOrgPerson') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,ldapx_persons WHERE ldapx_persons.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND upper(ldap_entries.dn) LIKE upper('%'||?) AND ldapx_persons.lang=0 AND (upper(ldapx_persons.surname) LIKE '%бугров%')

1 0

(ITS#8246) defining multiple frontend DBs should probably not be allowed
by ryan＠openldap.org 16 Sep '15

16 Sep '15

Full_Name: Ryan Tandy Version: 2.4, master OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan In #openldap, IsoLinCHiP noted that the following config works as intended, and asked whether it's supported: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.base="cn=admin,cn=config" manage by * +0 break dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config dn: olcDatabase={1}frontend,cn=config objectClass: olcDatabaseConfig%obobjectClass: olcFrontendConfig olcDatabase: {1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=subschema" by * read olcAccess: {2}to dn.subtree="dc=de" attrs=userPassword,userPKCS12 by * auth dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /usr/local/openldap/var/openldap-data olcRootDN: cn=admin,cn=config olcSuffix: dc=de The current behaviour is that the additional ACLs on olcDatabase={1}frontend get appended to the frontendDB ACL just as if they'd been defined on olcDatabase={-1}frontend. Behaviour for other attributes varies: some are merged with earlier values, or overwrite them; others are rejected. It seems to me that defining a second frontend is neither supported, nor to be depended upon, and therefore should probably be explicitly disallowed. Am I right?

1 0

(ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by geert＠hendrickx.be 14 Sep '15

14 Sep '15

Full_Name: Geert Hendrickx Version: 2.4.42 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.123.14.2) Currently the ManageDsaIt control allows bypassing attribute uniqueness constraints as implemented by slapo-unique(5). This seems inappropriate as the ManageDsaIt control (RFC 3296) is intended for managing referral objects. Also it is set by default by certain clients (specifically Java JNDI) which makes uniqueness constraints practically useless with such clients. The newer Relax Rules control (draft-zeilenga-ldap-relax) seems much more appropriate for this use case, please consider using it instead. The simple pchch below works for me, but I haven't tested its interaction with replication. Geert --- servers/slapd/overlays/unique.c 2015-08-14 17:25:28.000000000 +0200 +++ servers/slapd/overlays/unique.c 2015-09-07 22:00:44.217833199 +0200 @@ -1038,9 +1038,8 @@ Debug(LDAP_DEBUG_TRACE, "==> unique_add <%s>\n", op->o_req_dn.bv_val, 0, 0); - /* skip the checks if the operation has manageDsaIt control in it - * (for replication) */ - if ( op->o_managedsait > SLAP_CONTROL_IGNORED + /* skip the checks if the operation has relax control in it */ + if ( op->o_relax > SLAP_CONTROL_IGNORED && access_allowed ( op, op->ora_e, slap_schema.si_ad_entry, NULL, ACL_MANAGE, NULL ) ) { @@ -1170,9 +1169,8 @@ Debug(LDAP_DEBUG_TRACE, "==> unique_modify <%s>\n", op->o_req_dn.bv_val, 0, 0); - /* skip the checks if the operation has manageDsaIt control in it - * (for replication) */ - if ( op->o_managedsait > SLAP_CONTROL_IGNORED + /* skip the checks if the operation has relax control in it */ + if ( op->o_relax > SLAP_CONTROL_IGNORED && overlay_entry_get_ov(op, &op->o_req_ndn, NULL, NULL, 0, &e, on) == LDAP_SUCCESS && e && access_allowed ( op, e, @@ -1301,9 +1299,8 @@ Debug(LDAP_DEBUG_TRACE, "==> unique_modrdn <%s> <%s>\2222, op->o_req_dn.bv_val, op->orr_newrdn.bv_val, 0); - /* skip the checks if the operation has manageDsaIt control in it - * (for replication) */ - if ( op->o_managedsait > SLAP_CONTROL_IGNORED + /* skip the checks if the operation has relax control in it */ + if ( op->o_relax > SLAP_CONTROL_IGNORED && overlay_entry_get_ov(op, &op->o_req_ndn, NULL, NULL, 0, &e, on) == LDAP_SUCCESS && e && access_allowed ( op, e, --- doc/man/man5/slapo-unique.5 2015-08-14 17:25:28.000000000 +0200 +++ doc/man/man5/slapo-unique.5 2015-09-14 09:22:26.242624918 +0200 @@ -162,7 +162,7 @@ maximum flexibility in meeting site-specific requirements. .LP Replication and operations with -.B manageDsaIt +.B relax control are allowed to bypass this enforcement. It is therefore important that all servers accepting writes have this overlay configured in order to maintain uniqueness in a replicated DIT.

1 0

(ITS#8244) back-ldap entry_get is wrong
by hyc＠openldap.org 14 Sep '15

14 Sep '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.236.74) Submitted by: hyc The be_entry_get() entry point is only used for internal operations, not client-initiated operations. Currently it propagates client-provided controls through, but they don't belong there. If be_entry_get is invoked due to an ACL evaluation, and the original client operation was a syncrepl search, and the remote server honors the syncrepl control, then this query may hang because ldap_back_entry_get() doesn't expect to handle any Intermediate responses. Worse, if the control requested RefreshAndPersist, then additional responses may pile up on the session as the remote server sends persist updates.

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by hyc＠symas.com 12 Sep '15

12 Sep '15

Michael Ströder wrote: > hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> On 12/09/15 16:24, michael(a)stroeder.com wrote: >>>> I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not >>>> help. slapd still crashes when hitting the assert. >>> >>> Yes, portable.h #undefs it by default. OpenLDAP has always conflated >>> logging, debug output and asserts behind LDAP_DEBUG. We've been saying >>> for some time that we really ought to do something about that someday... >> >> Yes, and that's more obviously a bug that we can fix. > > Is it an easy fix? Not for 2.4. > I think that in opposite to the OpenLDAP project most people out there > consider this to be a really serious bug to be fixed really soon. > For now with my own builds I apply the patch removing the assert statement. > But I wonder how many asserts statements are in the code which can be hit by > invalid input leading to a crash. Given the lack of OpenLDAP documentation about NDEBUG I have re-reverted my previous revert. The patch has been reinstated. >> Every use of assert is "assert(the code is correct)" - but that often depends >> on dynamic state, not just the statically written code. > > Yes, dynamic state including invalid input. But IMO "assert(the code is > correct)" should never be hit no matter how bad the input was. And it should > definitely not crash the server (with system's ressource limits being a > unavoidable exception). Rephrasing: The meaning of the statement "the code is > correct" should also include "invalid input is properly handled as error" - no > matter what. In this particular case the code already handles the error perfectly well without the assert, so the assert doesn't serve any useful purpose. -- -- 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#8240) OpenLDAP ber_get_next denial of service vulnerability
by michael＠stroeder.com 12 Sep '15

12 Sep '15

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> On 12/09/15 16:24, michael(a)stroeder.com wrote: >>> I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not >>> help. slapd still crashes when hitting the assert. >> >> Yes, portable.h #undefs it by default. OpenLDAP has always conflated >> logging, debug output and asserts behind LDAP_DEBUG. We've been saying >> for some time that we really ought to do something about that someday... > > Yes, and that's more obviously a bug that we can fix. Is it an easy fix? I think that in opposite to the OpenLDAP project most people out there consider this to be a really serious bug to be fixed really soon. For now with my own builds I apply the patch removing the assert statement. But I wonder how many asserts statements are in the code which can be hit by invalid input leading to a crash. >> Even ignoring that, demanding -NDEBUG is backwards in so many ways: >> >> Using C's features like <assert.h> is not the user's job, it's >> OpenLDAP's (i.e. configure and portable.hin). The person building >> OpenLDAP might not even be a C programmer who knows about the C >> language quirk that it has a feature makes errors crash by default. > > It is standard practice in C code. assert() and NDEBUG are part of the C > standard. A person who doesn't know C has no business building the code. > Certainly the libraries are of no use to them if they're not C programmers > already. This is a black-and-white-only statement which does not meet 90% of the cases out there. >> A simple "./configure --prefix=/whatever" ought to be a reasonable way >> to build OpenLDAP, like with most other packages. There are >> installation instructions and they do not mention NDEBUG. I strongly concur with Hallvard here. > Every use of assert is "assert(the code is correct)" - but that often depends > on dynamic state, not just the statically written code. Yes, dynamic state including invalid input. But IMO "assert(the code is correct)" should never be hit no matter how bad the input was. And it should definitely not crash the server (with system's ressource limits being a unavoidable exception). Rephrasing: The meaning of the statement "the code is correct" should also include "invalid input is properly handled as error" - no matter what. Ciao, Michael.

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by hyc＠symas.com 12 Sep '15

12 Sep '15

h.b.furuseth(a)usit.uio.no wrote: > On 12/09/15 16:24, michael(a)stroeder.com wrote: >> I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not >> help. slapd still crashes when hitting the assert. > > Yes, portable.h #undefs it by default. OpenLDAP has always conflated > logging, debug output and asserts behind LDAP_DEBUG. We've been saying > for some time that we really ought to do something about that someday... Yes, and that's more obviously a bug that we can fix. > Even ignoring that, demanding -NDEBUG is backwards in so many ways: > > Using C's features like <assert.h> is not the user's job, it's > OpenLDAP's (i.e. configure and portable.hin). The person building > OpenLDAP might not even be a C programmer who knows about the C > language quirk that it has a feature makes errors crash by default. It is standard practice in C code. assert() and NDEBUG are part of the C standard. A person who doesn't know C has no business building the code. Certainly the libraries are of no use to them if they're not C programmers already. > A simple "./configure --prefix=/whatever" ought to be a reasonable way > to build OpenLDAP, like with most other packages. There are > installation instructions and they do not mention NDEBUG. > > In particular since this isn't even about catching a bug in OpenLDAP, > but in the input. If someone wants to crash-debug the input to slapd, > let him #define something when building slapd. You could replace the > assert() with debug_assert() or something. The same goes for any > other assert which doesn't mean "assert(the code is correct)". Every use of assert is "assert(the code is correct)" - but that often depends on dynamic state, not just the statically written code. Just like "assert(SOCKBUF_VALID(sb))" or whatever else. That is the case for the assert in question here. -- -- 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#7964) overlay rwm escape issue with more the 9 rules / rewrite statements
by ryan＠nardis.ca 12 Sep '15

12 Sep '15

Hi Michael, On Sat, Sep 12, 2015 at 02:38:44PM +0200, Michael Str=F6der wrote: >I wonder whether that caused a regression parsing multi-line DESC '..' in >schema descriptions. > >Up to now I could load this but it does not work with current RE24 branch: > >objectClass ( 1.3.6.1.4.1.412.100.2.1.3.2 NAME 'dlm1ManagedSystemElement' > DESC 'ManagedSystemElement is the base class for the > System Element hierarchy. Membership Criteria: Any > distinguishable component of a System is a candidate > for inclusion in this class. Examples: software > components, such as files; and devices, such as disk > drives and controllers, and physical components such > as chips and cards.' > SUP dlm1ManagedElement ABSTRACT > MAY ( dlmInstallDate $ dlmName $ dlmStatus ) ) > >This is not schema generated by me. A schema with the above DESC (including line breaks), and SUP top=20 ABSTRACT MAY description, is working fine for me on RE24 (as of c5b4cd6)=20 configured with "--disable-bdb --disable-hdb --enable-rwm". I tested embedding it directly in slapd.conf, including via 'include=20 test.schema', and ldapadd'ing an LDIF version into cn=3Dconfig at runtime. = =20 (admittedly the last is probably not relevant, since it becomes one long=20 logical LDIF line.) Can you provide some more details about the failure you see? Glancing at the RE24 log, I'd look at ITS#8233 as the change most likely=20 to be related, but can't say anything for sure without a reproducible=20 test case. thanks, Ryan

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by h.b.furuseth＠usit.uio.no 12 Sep '15

12 Sep '15

I wrote: > If someone wants to crash-debug the input to slapd, > let him #define something when building slapd. You could replace the > assert() with debug_assert() or something. The same goes for any > other assert which doesn't mean "assert(the code is correct)". Look at LDAP_MEMORY_DEBUG and its doc in liblber/memory.c, for example. With the note "* ... If LDAP_MEMORY_DEBUG & 2 is true, * that includes asserts known to break both slapd and current clients."

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs