- openldap-bugs - openldap.org

(ITS#8010) LMDB: New mdb_txn_begin() flag to init as reset
by scott＠GameRanger.com 22 Dec '14

22 Dec '14

Full_Name: Scott Kevill Version: n/a OS: n/a URL: Submission from: (NULL) (101.166.148.57) Using a read-only txn with mdb_txn_reset() and mdb_txn_renew() is a little clumsy at the moment because the first use needs to be a mdb_txn_begin(). This means either an initial mdb_txn_begin() + mdb_txn_reset() to get it into the reset state, or else for every operation to do something like: if (txn) mdb_txn_renew() else mdb_txn_begin() ... do work ... mdb_txn_reset() An additional flag (eg. MDB_RESET?) for mdb_txn_begin() that only worked in conjunction with MDB_RDONLY could save that (minor) wasted work.

1 0

Re: (ITS#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by michael＠stroeder.com 20 Dec '14

20 Dec '14

ondra(a)mistotebe.net wrote: > On Fri, Dec 19, 2014 at 02:41:55AM +0000, michael(a)stroeder.com wrote: >> Just because I'm curious: >> >> What's the use-case for setting size and count to zero? >> >> If one wants to forbid an attribute completely one should probably use >> NOT in a DIT content rule for the STRUCTURAL object class. >> (This does not mean that this shouldn't be fixed though.) > > I personally thought that OpenLDAP did not implement DIT content rules > at all. DIT *content* rules are implemented and I'm using NOT quite often to reject attributes I don't need in a deployment. Kind of a local profile for standard schema. DIT *structure* rules and name forms are not supported yet. Ciao, Michael.

1 0

Re: (ITS#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by ondra＠mistotebe.net 20 Dec '14

20 Dec '14

On Fri, Dec 19, 2014 at 02:41:55AM +0000, michael(a)stroeder.com wrote: > Just because I'm curious: > > What's the use-case for setting size and count to zero? > > If one wants to forbid an attribute completely one should probably use > NOT in a DIT content rule for the STRUCTURAL object class. > (This does not mean that this shouldn't be fixed though.) I personally thought that OpenLDAP did not implement DIT content rules at all.

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

Michael Ströder wrote: > Quanah Gibson-Mount wrote: >> --On Friday, December 19, 2014 11:29 PM +0100 Michael Ströder >> <michael(a)stroeder.com> wrote: >> >>>> 2.4 is for bugfixes and regressions only. >> >> See above. > > Well, I consider it to be a serious defect that the old *Record attribute type > descriptions defined in obsoleted RFC 1274 are still in cosine.(ldif|schema) > even though they are not in RFC 4524. > > I also consider it to be a bug that aRecord and aAAARecord don't have the same > attribute type description. Hmm, this issue with cosine.(ldif|schema) is sitting in ITS since more than four years: ITS#6151 (slipped from my memory before filing this issue) Ciao, Michael.

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

Quanah Gibson-Mount wrote: > --On Friday, December 19, 2014 11:29 PM +0100 Michael Ströder > <michael(a)stroeder.com> wrote: > >>> 2.4 is for bugfixes and regressions only. > > See above. Well, I consider it to be a serious defect that the old *Record attribute type descriptions defined in obsoleted RFC 1274 are still in cosine.(ldif|schema) even though they are not in RFC 4524. I also consider it to be a bug that aRecord and aAAARecord don't have the same attribute type description. Ciao, Michael.

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by quanah＠zimbra.com 19 Dec '14

19 Dec '14

--On Friday, December 19, 2014 11:29 PM +0100 Michael Str=C3=B6der=20 <michael(a)stroeder.com> wrote: >> 2.4 is for bugfixes and regressions only. See above. -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

This is a cryptographically signed message in MIME format. --------------ms040409080506030800020107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable quanah(a)zimbra.com wrote: > --On Friday, December 19, 2014 8:25 PM +0000 michael(a)stroeder.com wrote= : >=20 >> There isn't a new version of the COSINE schema. >> >> But the attributes defined in RFC 1274, which were not added to RFC 45= 24 >> [1], are used in the usual DNS zone schema which defines object class >> 'dNSDomain2'. The DNS zone schema defines more attributes for DNS RRs = and >> all of them have a SUBSTR matching rule defined. >> >> If you reject this patch because you don't want to change a "standard"= >> schema the other possibility would be to completely hunk out these RFC= >> 1274 declarations from cosine.(schema|ldif) to avoid collision with >> separate DNS schema files adding them. >> >> [1] http://tools.ietf.org/html/rfc4524#appendix-A.4 >=20 > This sounds like a 2.5 feature request then. We can keep it in mind fo= r=20 > that. >=20 > 2.4 is for bugfixes and regressions only. My patch would be trivial and without causing any harm. Ciao, Michael. --------------ms040409080506030800020107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNDEyMTkyMjI5NTlaMCMGCSqGSIb3DQEJBDEWBBR+22VvvmCp +A94Q+dBdVogbCCyDDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAtSohllra XuuH1iDkuh5hnextf2Q78lXhr6Z6LW3jBy1O7lh0eT84ib/PGWMQSFtQzt6hWlJH9CChsS19 QQZNRgntzc557fBs023zIbvH3JR+Yr32jKTHvOvbTZOjWf4rU3B7hn4kcgKKvVd7dkx74eT9 gjNVYGSfQNagHdXCEuXkijvA0SwcBrmT9sU44CMUHS45a7kfza0Qihjxli8Cf3lJTty5ROy+ PdqW9XdFqKhP9Lf/dX1IdCIZ+32Eku7thoSuPs7vO2Di6KjQk5RVDx+EPqcnuBpHo9lFvKfi rAoxx5LoY0ZOGsxBOnDs3h4idzmCqdsBcTPjFp6SZH4glAAAAAAAAA== --------------ms040409080506030800020107--

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by quanah＠zimbra.com 19 Dec '14

19 Dec '14

--On Friday, December 19, 2014 8:25 PM +0000 michael(a)stroeder.com wrote: > There isn't a new version of the COSINE schema. > > But the attributes defined in RFC 1274, which were not added to RFC 4524 > [1], are used in the usual DNS zone schema which defines object class > 'dNSDomain2'. The DNS zone schema defines more attributes for DNS RRs and > all of them have a SUBSTR matching rule defined. > > If you reject this patch because you don't want to change a "standard" > schema the other possibility would be to completely hunk out these RFC > 1274 declarations from cosine.(schema|ldif) to avoid collision with > separate DNS schema files adding them. > > Ciao, Michael. > > [1] http://tools.ietf.org/html/rfc4524#appendix-A.4 This sounds like a 2.5 feature request then. We can keep it in mind for that. 2.4 is for bugfixes and regressions only. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

Howard Chu wrote: > I didn't know there was a new revision of the COSINE schema. Where was it > published? There isn't a new version of the COSINE schema. But the attributes defined in RFC 1274, which were not added to RFC 4524 [1], are used in the usual DNS zone schema which defines object class 'dNSDomain2'. The DNS zone schema defines more attributes for DNS RRs and all of them have a SUBSTR matching rule defined. If you reject this patch because you don't want to change a "standard" schema the other possibility would be to completely hunk out these RFC 1274 declarations from cosine.(schema|ldif) to avoid collision with separate DNS schema files adding them. Ciao, Michael. [1] http://tools.ietf.org/html/rfc4524#appendix-A.4

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by hyc＠symas.com 19 Dec '14

19 Dec '14

michael(a)stroeder.com wrote: > Full_Name: > Version: HEAD > OS: > URL: > Submission from: (NULL) (79.219.126.25) > > > SUBSTR caseIgnoreIA5SubstringsMatch should be added to attributes *Record in > cosine schema files to be compatible to attributes defined in UNINETT's DNS > schema files. I didn't know there was a new revision of the COSINE schema. Where was it published? -- -- 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#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

This is a cryptographically signed message in MIME format. --------------ms010702010502010600050002 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Another question in this context: Wouldn't it make sense to keep the matchingRuleUse descriptions in sync? Unfortunately they are in schema_prep.c. :-( Or maybe slapd should automagically update matchingRuleUse according to attribute type descriptions found in the subschema. One could argue that APPLIES in matchingRuleUse is not well designed beca= use it references attribute types and instead of LDAP syntaxes. Background: I was wondering whether I could work around missing SUBSTR matching rules= in web2ldap by looking at matchingRuleUse and auto-generate appropriate extensible filters=85 Ciao, Michael. --------------ms010702010502010600050002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNDEyMTkxMDUyMzZaMCMGCSqGSIb3DQEJBDEWBBSbfY9Fm0K6 dPiZuj/OvYAFG2tsVzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAv4gHo1JQ 6MbHxiLVIx/M9XSeHMakWCgFoadXIQ5Ha32sZohORTmUWEJC/FtEXTvpLBAho4BRbCtIYfxd pSBmurQwZjyH7AknXTmtpCCyMzs5fOxJN+rGgnu102EHFAVKwgAFxY0/wkdWNDhYujHRmIUA ty+j0MjbcG7EWq4FP4vCEiz2lr6mfABL1Gg2tsPLqklQ+WQlR733awXUQ+8yf9rG7BSLOsGR qx9ZJNXTruaCE7/CrQSLsEeeX7HG9sSqb8LQ5gVvrL8p97zcBVJNJB4skWPbRPw9tnpw91sW Ivwvt67JQydZBEMs6MOpss2UMru0ZeN0pEHRlrj2gFVgWAAAAAAAAA== --------------ms010702010502010600050002--

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

Hmmpf! ITS destroys formatting. See also: http://www.stroeder.com/temp/openldap-its-8009.patch

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

This is a multi-part message in MIME format. --------------040505080606070501000304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Find attached a patch file for this. I'd be glad if this could make it into 2.4.41. I, Michael Ströder, hereby place the attached modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. --------------040505080606070501000304 Content-Type: text/x-patch; name="openldap-its-8009.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="openldap-its-8009.patch" diff --git a/servers/slapd/schema/cosine.ldif b/servers/slapd/schema/cosi= ne.ldif index d207111..d37a988 100644 --- a/servers/slapd/schema/cosine.ldif +++ b/servers/slapd/schema/cosine.ldif @@ -80,18 +80,24 @@ olcAttributeTypes: ( 0.9.2342.19200300.100.1.21 NAME = 'secretary' DESC 'RFC 6.115.121.1.12 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.22 NAME 'otherMailbox' SYNT= AX 1.3.6.1.4.1.1466.115.121.1.39 ) -olcAttributeTypes: ( 0.9.2342.19200300.100.1.26 NAME 'aRecord' EQUALITY = ca - seIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) -olcAttributeTypes: ( 0.9.2342.19200300.100.1.27 NAME 'mDRecord' EQUALITY= c - aseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) -olcAttributeTypes: ( 0.9.2342.19200300.100.1.28 NAME 'mXRecord' EQUALITY= c - aseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) -olcAttributeTypes: ( 0.9.2342.19200300.100.1.29 NAME 'nSRecord' EQUALITY= c - aseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) -olcAttributeTypes: ( 0.9.2342.19200300.100.1.30 NAME 'sOARecord' EQUALIT= Y=20 - caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) -olcAttributeTypes: ( 0.9.2342.19200300.100.1.31 NAME 'cNAMERecord' EQUAL= IT - Y caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) +olcAttributeTypes: ( 0.9.2342.19200300.100.1.26 NAME 'aRecord'=20 + EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch=20 + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) +olcAttributeTypes: ( 0.9.2342.19200300.100.1.27 NAME 'mDRecord'=20 + EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch=20 + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) +olcAttributeTypes: ( 0.9.2342.19200300.100.1.28 NAME 'mXRecord'=20 + EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch=20 + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) +olcAttributeTypes: ( 0.9.2342.19200300.100.1.29 NAME 'nSRecord'=20 + EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch=20 + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) +olcAttributeTypes: ( 0.9.2342.19200300.100.1.30 NAME 'sOARecord'=20 + EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch=20 + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) +olcAttributeTypes: ( 0.9.2342.19200300.100.1.31 NAME 'cNAMERecord'=20 + EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch=20 + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.38 NAME 'associatedName' DE= SC 'RFC1274: DN of entry associated with domain' EQUALITY distinguishedNa= meMatc h SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) diff --git a/servers/slapd/schema/cosine.schema b/servers/slapd/schema/co= sine.schema index 8ea7090..6706525 100644 --- a/servers/slapd/schema/cosine.schema +++ b/servers/slapd/schema/cosine.schema @@ -477,12 +477,14 @@ attributetype ( 0.9.2342.19200300.100.1.22 NAME 'ot= herMailbox' ## incorrect syntax? attributetype ( 0.9.2342.19200300.100.1.26 NAME 'aRecord' EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) =20 ## missing from RFC1274 ## incorrect syntax? attributetype ( 0.9.2342.19200300.100.1.27 NAME 'mDRecord' EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) =20 # 9.3.23. MX Record @@ -498,6 +500,7 @@ attributetype ( 0.9.2342.19200300.100.1.27 NAME 'mDRe= cord' ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.28 NAME 'mXRecord' EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) =20 # 9.3.24. NS Record @@ -513,6 +516,7 @@ attributetype ( 0.9.2342.19200300.100.1.28 NAME 'mXRe= cord' ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.29 NAME 'nSRecord' EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) =20 # 9.3.25. SOA Record @@ -528,6 +532,7 @@ attributetype ( 0.9.2342.19200300.100.1.29 NAME 'nSRe= cord' ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.30 NAME 'sOARecord' EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) =20 # 9.3.26. CNAME Record @@ -543,6 +548,7 @@ attributetype ( 0.9.2342.19200300.100.1.30 NAME 'sOAR= ecord' ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.31 NAME 'cNAMERecord' EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) =20 # 9.3.27. Associated Domain --------------040505080606070501000304--

1 0

(ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (79.219.126.25) SUBSTR caseIgnoreIA5SubstringsMatch should be added to attributes *Record in cosine schema files to be compatible to attributes defined in UNINETT's DNS schema files. Patch will follow.

1 0

Re: (ITS#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by michael＠stroeder.com 18 Dec '14

18 Dec '14

hyc(a)symas.com wrote: > ondra(a)mistotebe.net wrote: >> On Wed, Dec 17, 2014 at 03:33:32PM +0000, hyc(a)symas.com wrote: >>> Hello Ondrej, >>> I tried your patch but it breaks test064-constraint. >> >> Hi Howard, >> there is useless code that caused it to read an unitialized variable. A >> fix removing that code is at >> ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20141218-ITS-7781.patch >> >> Thanks for identifying and fixing the problem in the meantime. >> > Ok. But looking at this patch, the lines in question actually are > needed, since they take care of errors in the cases for CONSTRAINT_COUNT > and CONSTRAINT_SET. Just because I'm curious: What's the use-case for setting size and count to zero? If one wants to forbid an attribute completely one should probably use NOT in a DIT content rule for the STRUCTURAL object class. (This does not mean that this shouldn't be fixed though.) Just my 2 cents. Ciao, Michael.

1 0

Re: (ITS#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by hyc＠symas.com 18 Dec '14

18 Dec '14

ondra(a)mistotebe.net wrote: > On Wed, Dec 17, 2014 at 03:33:32PM +0000, hyc(a)symas.com wrote: >> Hello Ondrej, >> I tried your patch but it breaks test064-constraint. > > Hi Howard, > there is useless code that caused it to read an unitialized variable. A > fix removing that code is at > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20141218-ITS-7781.patch > > Thanks for identifying and fixing the problem in the meantime. > Ok. But looking at this patch, the lines in question actually are needed, since they take care of errors in the cases for CONSTRAINT_COUNT and CONSTRAINT_SET. -- -- 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#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by ondra＠mistotebe.net 18 Dec '14

18 Dec '14

On Thu, Dec 18, 2014 at 09:42:18PM +0000, ondra(a)mistotebe.net wrote: > Hi Howard, > there is useless code that caused it to read an unitialized variable. A > fix removing that code is at > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20141218-ITS-7781.patch Nevermind that, that code is needed and I should be running static analysers more often when it's late.

1 0

Re: (ITS#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by ondra＠mistotebe.net 18 Dec '14

18 Dec '14

On Wed, Dec 17, 2014 at 03:33:32PM +0000, hyc(a)symas.com wrote: > Hello Ondrej, > I tried your patch but it breaks test064-constraint. Hi Howard, there is useless code that caused it to read an unitialized variable. A fix removing that code is at ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20141218-ITS-7781.patch Thanks for identifying and fixing the problem in the meantime.

1 0

Re: (ITS#8005) crash when multiple olcDbURI are defined for chaining
by hyc＠symas.com 17 Dec '14

17 Dec '14

Khosrow Ebrahimpour wrote: > > On 12/17/2014 03:22 PM, Howard Chu wrote: >>>> Note that test032-chain in the test suite tests a config with two URIs >>>> and it passes successfully. >>> From what I see although test032 tests two URIs, it doesn't test two >>> URIs defined in the same olcDbURI field. The crash I've discovered only >>> occurs when two URIs are defined at the same time. And like I mentioned >>> in the issue report, this should be valid according to the man-page. No. slapo-chain(5) states explicitly: chain-uri <ldapuri> This directive instantiates a new underlying ldap database and instructs it about which URI to contact to chase referrals. As opposed to what stated in slapd-ldap(5), only one URI can appear after this directive; Closing this ITS. -- -- 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#8005) crash when multiple olcDbURI are defined for chaining
by khosrow.ebrahimpour＠ssc-spc.gc.ca 17 Dec '14

17 Dec '14

On 12/16/2014 04:47 PM, Howard Chu wrote: > Khosrow Ebrahimpour wrote: >> >> On 12/15/2014 01:20 PM, Howard Chu wrote: >>> khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >>>> On 12/15/2014 12:09 PM, Howard Chu wrote: >>>>> khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >>>>>> Full_Name: K. Ebrahimpour >>>>>> Version: RE24 (commit dbc6741750de79b852ec9f728abb8b1425b6f03f) >>>>>> OS: Ubuntu 14.04.1 >>>>>> URL: https://gist.github.com/khosrow/cc6640cad9275a2cd041 >>>>>> Submission from: (NULL) (205.211.133.128) >>>>> >>>>>> Finally, I'm running OpenLDAP 2.4.31 on Ubuntu Trusty, but was also >>>>>> able to >>>>>> replicate this same error on OpenLDAP 2.4.28 on Ubuntu Precise. >>>>> >>>>> The current release is 2.4.40. For such old releases you should >>>>> contact Ubuntu for support. >>>>> >>>> I may not have been clear enough on which versions I have tested. >>>> Please >>>> see the *VERSION* field in the ITS submission form for the correct >>>> version. >>>> >>>> To clarify, I have tested and reproduced the bug on the following >>>> versions: >>>> >>>> * 2.4.28 on Ubuntu 12.04 (official Ubuntu package) >>>> * 2.4.31 on Ubuntu 14.04 (official Ubuntu package) >>>> * RE24 commit #dbc6741750de79b852ec9f728abb8b1425b6f03f on Ubuntu >>>> 14.04 >>>> (from OpenLDAP git repo) >>>> >>>> I understand the two first instances are old releases, I simply tested >>>> the bug on progressively newer versions of the software. Are you >>>> saying >>>> that the third tested version is also old? >>> >>> That commit ID is a few months old, from before 2.4.40 was released. >>> We are currently preparing to release 2.4.41, so yes, it's old. >>> >> Bug confirmed and replicated against OPENLDAP_REL_ENG_2_4 branch on >> commit 87c3614bee6de3a29ff95e311b2870322f1e35f0. I have updated the gist >> (in the bug report) with a new crash log from the replica server. > > Note that test032-chain in the test suite tests a config with two URIs > and it passes successfully. From what I see although test032 tests two URIs, it doesn't test two URIs defined in the same olcDbURI field. The crash I've discovered only occurs when two URIs are defined at the same time. And like I mentioned in the issue report, this should be valid according to the man-page. > > 1) provide a gdb stack trace of your crash > 2) provide a complete config that reproduces your crash, including the > data and commands used. Crash data now available at http://khosrow.ca/its8005 > > It might be easiest for you to edit the test032 setup to match yours. > Thanks,

1 0

Re: (ITS#8008) proxyauth with saslmech EXTERNAL not working
by hyc＠symas.com 17 Dec '14

17 Dec '14

hyc(a)symas.com wrote: > Looks like you've compiled without DEBUG enabled, otherwise your 2.4.26 > build would have died with an assert() failure there. > > Send a complete config that reproduces the issue. Repeating myself: > Also give the complete > command you used. -- -- 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#8008) proxyauth with saslmech EXTERNAL not working
by hyc＠symas.com 17 Dec '14

17 Dec '14

Dirk Kastens wrote: > Hi, > > I have attached my config directory. For future reference - just use slapcat -n0. The slapd config database internal format will not always be a directory tree, but slapcat will always do the right thing. -- -- 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#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by hyc＠symas.com 17 Dec '14

17 Dec '14

Hello Ondrej, I tried your patch but it breaks test064-constraint. -- -- 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#8005) crash when multiple olcDbURI are defined for chaining
by hyc＠symas.com 16 Dec '14

16 Dec '14

Khosrow Ebrahimpour wrote: > > On 12/15/2014 01:20 PM, Howard Chu wrote: >> khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >>> On 12/15/2014 12:09 PM, Howard Chu wrote: >>>> khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >>>>> Full_Name: K. Ebrahimpour >>>>> Version: RE24 (commit dbc6741750de79b852ec9f728abb8b1425b6f03f) >>>>> OS: Ubuntu 14.04.1 >>>>> URL: https://gist.github.com/khosrow/cc6640cad9275a2cd041 >>>>> Submission from: (NULL) (205.211.133.128) >>>> >>>>> Finally, I'm running OpenLDAP 2.4.31 on Ubuntu Trusty, but was also >>>>> able to >>>>> replicate this same error on OpenLDAP 2.4.28 on Ubuntu Precise. >>>> >>>> The current release is 2.4.40. For such old releases you should >>>> contact Ubuntu for support. >>>> >>> I may not have been clear enough on which versions I have tested. Please >>> see the *VERSION* field in the ITS submission form for the correct >>> version. >>> >>> To clarify, I have tested and reproduced the bug on the following >>> versions: >>> >>> * 2.4.28 on Ubuntu 12.04 (official Ubuntu package) >>> * 2.4.31 on Ubuntu 14.04 (official Ubuntu package) >>> * RE24 commit #dbc6741750de79b852ec9f728abb8b1425b6f03f on Ubuntu 14.04 >>> (from OpenLDAP git repo) >>> >>> I understand the two first instances are old releases, I simply tested >>> the bug on progressively newer versions of the software. Are you saying >>> that the third tested version is also old? >> >> That commit ID is a few months old, from before 2.4.40 was released. >> We are currently preparing to release 2.4.41, so yes, it's old. >> > Bug confirmed and replicated against OPENLDAP_REL_ENG_2_4 branch on > commit 87c3614bee6de3a29ff95e311b2870322f1e35f0. I have updated the gist > (in the bug report) with a new crash log from the replica server. Note that test032-chain in the test suite tests a config with two URIs and it passes successfully. 1) provide a gdb stack trace of your crash 2) provide a complete config that reproduces your crash, including the data and commands used. It might be easiest for you to edit the test032 setup to match yours. -- -- 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#8005) crash when multiple olcDbURI are defined for chaining
by khosrow.ebrahimpour＠ssc-spc.gc.ca 16 Dec '14

16 Dec '14

On 12/15/2014 01:20 PM, Howard Chu wrote: > khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >> On 12/15/2014 12:09 PM, Howard Chu wrote: >>> khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >>>> Full_Name: K. Ebrahimpour >>>> Version: RE24 (commit dbc6741750de79b852ec9f728abb8b1425b6f03f) >>>> OS: Ubuntu 14.04.1 >>>> URL: https://gist.github.com/khosrow/cc6640cad9275a2cd041 >>>> Submission from: (NULL) (205.211.133.128) >>> >>>> Finally, I'm running OpenLDAP 2.4.31 on Ubuntu Trusty, but was also >>>> able to >>>> replicate this same error on OpenLDAP 2.4.28 on Ubuntu Precise. >>> >>> The current release is 2.4.40. For such old releases you should >>> contact Ubuntu for support. >>> >> I may not have been clear enough on which versions I have tested. Please >> see the *VERSION* field in the ITS submission form for the correct >> version. >> >> To clarify, I have tested and reproduced the bug on the following >> versions: >> >> * 2.4.28 on Ubuntu 12.04 (official Ubuntu package) >> * 2.4.31 on Ubuntu 14.04 (official Ubuntu package) >> * RE24 commit #dbc6741750de79b852ec9f728abb8b1425b6f03f on Ubuntu 14.04 >> (from OpenLDAP git repo) >> >> I understand the two first instances are old releases, I simply tested >> the bug on progressively newer versions of the software. Are you saying >> that the third tested version is also old? > > That commit ID is a few months old, from before 2.4.40 was released. > We are currently preparing to release 2.4.41, so yes, it's old. > Bug confirmed and replicated against OPENLDAP_REL_ENG_2_4 branch on commit 87c3614bee6de3a29ff95e311b2870322f1e35f0. I have updated the gist (in the bug report) with a new crash log from the replica server. -- Khosrow

1 0

Re: (ITS#8008) proxyauth with saslmech EXTERNAL not working
by hyc＠symas.com 16 Dec '14

16 Dec '14

dkastens(a)uos.de wrote: > Full_Name: Dirk Kastens > Version: 2.4.40 > OS: RedHat SL 7.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:638:508:3d0:8d09:a681:a06e:29f0) > > > This is a duplicate of bug #7993 that has been closed. > > Meanwhile I compiled openldap myself. > > At first, I compiled openldap-2.4.40. I configured ldap as a replica server. It > connects with saslmech EXTERNAL to the master server. > When I configure idassert-bind with saslmech EXTERNAL and try to change an > entry, ldapmodify fails with > > ldap_modify: Other (e.g., implementation specific) error (80) > > slapd logs the message: > --------------------------- > send_ldap_result: referral="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" > >>> dnPrettyNormal: > <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> > <<< dnPrettyNormal: > <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de>, > <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> > conn=1000 op=1 ldap_chain_op: > ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" > -> "ldap://ldap-master.rz.uni-osnabrueck.de" > conn=1000 op=1 ldap_chain_op: > ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de": > URI="ldap://ldap-master.rz.uni-osnabrueck.de" found in cache > =>ldap_back_getconn: conn=1000 op=1: lc=0x7faca820bc70 inserted refcnt=1 > rc=0 > Error: ldap_back_is_proxy_authz returned 0, misconfigured URI? > send_ldap_result: conn=1000 op=1 p=3 > send_ldap_result: err=80 matched="" text="misconfigured URI?" > send_ldap_result: conn=1000 op=1 p=3 > send_ldap_result: err=80 matched="" text="" > send_ldap_response: msgid=2 tag=103 err=80 > --------------------------- > > Then I compiled openldap-2.4.26 and used the same configuration. The modify with > saslmech EXTERNAL succeeded: > > --------------------------- > send_ldap_result: conn=1001 op=1 p=3 > send_ldap_result: err=10 matched="" text="" > send_ldap_result: referral="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" > >>> dnPrettyNormal: > <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> > <<< dnPrettyNormal: > <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de>, > <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> > conn=1001 op=1 ldap_chain_op: > ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" > -> "ldap://ldap-master.rz.uni-osnabrueck.de" > conn=1001 op=1 ldap_chain_op: > ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de": > URI="ldap://ldap-master.rz.uni-osnabrueck.de" found in cache > =>ldap_back_getconn: conn=1001 op=1: lc=0x7f4f201fe6f0 inserted refcnt=1 > rc=0 > send_ldap_result: conn=1001 op=1 p=3 > send_ldap_result: err=0 matched="" text="" > send_ldap_response: msgid=2 tag=103 err=0 > --------------------------- > > With a quick look I found out, that the function ldap_back_dobind_int in > server/slapd/back-ldap/bind.c differs. In 2.4.26 you have: > > --------------------------- > if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { > if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( > &bindcred ) ) { > /* if we got here, it shouldn't return result */ > rc = ldap_back_is_proxy_authz( op, rs, > LDAP_BACK_DONTSEND, &binddn, &bindcred );A A assert( rc == > 1 ); > } > rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn, > &bindcred ); > goto done; > } > --------------------------- > > while in 2.4.40 there is: > > --------------------------- > if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { > if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( &bindcred ) ) > { > /* if we got here, it shouldn't return result */ > rc = ldap_back_is_proxy_authz( op, rs, > LDAP_BACK_DONTSEND, &binddn,2&bindcred ); > if ( rc != 1 ) { > Debug( LDAP_DEBUG_ANY, "Error: ldap_back_is_proxy_authz " > "returned %d, misconfigured URI?\n", rc, 0, 0 ); > rs->sr_err = LDAP_OTHER; > rs->sr_text = "misconfigured URI?"; > LP_P_BACK_CONN_ISBOUND_CLEAR( lc ); > if ( sendok & LDAP_BACK_SENDERR ) { > send_ldap_result( op, rs ); > } > goto done; > } > rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn, > &bindcred ); > goto done; > } > -------------------------- > > This is where the error message comes from ("misconfigured URI?") Looks like you've compiled without DEBUG enabled, otherwise your 2.4.26 build would have died with an assert() failure there. Send a complete config that reproduces the issue. Also give the complete command you used. So far this just looks like a misconfiguration to me. -- -- 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#8008) proxyauth with saslmech EXTERNAL not working
by dkastens＠uos.de 15 Dec '14

15 Dec '14

Full_Name: Dirk Kastens Version: 2.4.40 OS: RedHat SL 7.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:508:3d0:8d09:a681:a06e:29f0) This is a duplicate of bug #7993 that has been closed. Meanwhile I compiled openldap myself. At first, I compiled openldap-2.4.40. I configured ldap as a replica server. It connects with saslmech EXTERNAL to the master server. When I configure idassert-bind with saslmech EXTERNAL and try to change an entry, ldapmodify fails with ldap_modify: Other (e.g., implementation specific) error (80) slapd logs the message: --------------------------- send_ldap_result: referral="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" >>> dnPrettyNormal: <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> <<< dnPrettyNormal: <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de>, <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> conn=1000 op=1 ldap_chain_op: ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" -> "ldap://ldap-master.rz.uni-osnabrueck.de" conn=1000 op=1 ldap_chain_op: ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de": URI="ldap://ldap-master.rz.uni-osnabrueck.de" found in cache =>ldap_back_getconn: conn=1000 op=1: lc=0x7faca820bc70 inserted refcnt=1 rc=0 Error: ldap_back_is_proxy_authz returned 0, misconfigured URI? send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=80 matched="" text="misconfigured URI?" send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=80 matched="" text="" send_ldap_response: msgid=2 tag=103 err=80 --------------------------- Then I compiled openldap-2.4.26 and used the same configuration. The modify with saslmech EXTERNAL succeeded: --------------------------- send_ldap_result: conn=1001 op=1 p=3 send_ldap_result: err=10 matched="" text="" send_ldap_result: referral="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" >>> dnPrettyNormal: <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> <<< dnPrettyNormal: <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de>, <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> conn=1001 op=1 ldap_chain_op: ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" -> "ldap://ldap-master.rz.uni-osnabrueck.de" conn=1001 op=1 ldap_chain_op: ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de": URI="ldap://ldap-master.rz.uni-osnabrueck.de" found in cache =>ldap_back_getconn: conn=1001 op=1: lc=0x7f4f201fe6f0 inserted refcnt=1 rc=0 send_ldap_result: conn=1001 op=1 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=2 tag=103 err=0 --------------------------- With a quick look I found out, that the function ldap_back_dobind_int in server/slapd/back-ldap/bind.c differs. In 2.4.26 you have: --------------------------- if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( &bindcred ) ) { /* if we got here, it shouldn't return result */ rc = ldap_back_is_proxy_authz( op, rs, LDAP_BACK_DONTSEND, &binddn, &bindcred );A A assert( rc == 1 ); } rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn, &bindcred ); goto done; } --------------------------- while in 2.4.40 there is: --------------------------- if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( &bindcred ) ) { /* if we got here, it shouldn't return result */ rc = ldap_back_is_proxy_authz( op, rs, LDAP_BACK_DONTSEND, &binddn,2&bindcred ); if ( rc != 1 ) { Debug( LDAP_DEBUG_ANY, "Error: ldap_back_is_proxy_authz " "returned %d, misconfigured URI?\n", rc, 0, 0 ); rs->sr_err = LDAP_OTHER; rs->sr_text = "misconfigured URI?"; LP_P_BACK_CONN_ISBOUND_CLEAR( lc ); if ( sendok & LDAP_BACK_SENDERR ) { send_ldap_result( op, rs ); } goto done; } rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn, &bindcred ); goto done; } -------------------------- This is where the error message comes from ("misconfigured URI?")

1 0

(ITS#8007) Add option for restricting max entry size
by hyc＠openldap.org 15 Dec '14

15 Dec '14

Full_Name: Howard Chu Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Sometimes it would be useful to control how large an entry may be stored.

1 0

(ITS#8006) Inconsistent autogroup results
by hyc＠openldap.org 15 Dec '14

15 Dec '14

Full_Name: Howard Chu Version: 2.4.39 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc It looks like autogroup runs all its internal modifications using the same identity as the original op that triggered it. It should be using the rootDN, since the original user may not have permissions to search or modify all of the affected entries.

1 0

Re: (ITS#8005) crash when multiple olcDbURI are defined for chaining
by hyc＠symas.com 15 Dec '14

15 Dec '14

khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: > On 12/15/2014 12:09 PM, Howard Chu wrote: >> khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >>> Full_Name: K. Ebrahimpour >>> Version: RE24 (commit dbc6741750de79b852ec9f728abb8b1425b6f03f) >>> OS: Ubuntu 14.04.1 >>> URL: https://gist.github.com/khosrow/cc6640cad9275a2cd041 >>> Submission from: (NULL) (205.211.133.128) >> >>> Finally, I'm running OpenLDAP 2.4.31 on Ubuntu Trusty, but was also >>> able to >>> replicate this same error on OpenLDAP 2.4.28 on Ubuntu Precise. >> >> The current release is 2.4.40. For such old releases you should >> contact Ubuntu for support. >> > I may not have been clear enough on which versions I have tested. Please > see the *VERSION* field in the ITS submission form for the correct version. > > To clarify, I have tested and reproduced the bug on the following versions: > > * 2.4.28 on Ubuntu 12.04 (official Ubuntu package) > * 2.4.31 on Ubuntu 14.04 (official Ubuntu package) > * RE24 commit #dbc6741750de79b852ec9f728abb8b1425b6f03f on Ubuntu 14.04 > (from OpenLDAP git repo) > > I understand the two first instances are old releases, I simply tested > the bug on progressively newer versions of the software. Are you saying > that the third tested version is also old? That commit ID is a few months old, from before 2.4.40 was released. We are currently preparing to release 2.4.41, so yes, it's old. -- -- 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#8005) crash when multiple olcDbURI are defined for chaining
by quanah＠zimbra.com 15 Dec '14

15 Dec '14

--On Monday, December 15, 2014 6:07 PM +0000 khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: > * RE24 commit #dbc6741750de79b852ec9f728abb8b1425b6f03f on Ubuntu 14.04 > (from OpenLDAP git repo) That commit is from last September, and predates the 2.4.40 release. Again, please test against current RE24. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8005) crash when multiple olcDbURI are defined for chaining
by khosrow.ebrahimpour＠ssc-spc.gc.ca 15 Dec '14

15 Dec '14

On 12/15/2014 12:09 PM, Howard Chu wrote: > khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >> Full_Name: K. Ebrahimpour >> Version: RE24 (commit dbc6741750de79b852ec9f728abb8b1425b6f03f) >> OS: Ubuntu 14.04.1 >> URL: https://gist.github.com/khosrow/cc6640cad9275a2cd041 >> Submission from: (NULL) (205.211.133.128) > >> Finally, I'm running OpenLDAP 2.4.31 on Ubuntu Trusty, but was also >> able to >> replicate this same error on OpenLDAP 2.4.28 on Ubuntu Precise. > > The current release is 2.4.40. For such old releases you should > contact Ubuntu for support. > I may not have been clear enough on which versions I have tested. Please see the *VERSION* field in the ITS submission form for the correct version. To clarify, I have tested and reproduced the bug on the following versions: * 2.4.28 on Ubuntu 12.04 (official Ubuntu package) * 2.4.31 on Ubuntu 14.04 (official Ubuntu package) * RE24 commit #dbc6741750de79b852ec9f728abb8b1425b6f03f on Ubuntu 14.04 (from OpenLDAP git repo) I understand the two first instances are old releases, I simply tested the bug on progressively newer versions of the software. Are you saying that the third tested version is also old? Thanks, -- Khosrow

1 0

Re: (ITS#8005) crash when multiple olcDbURI are defined for chaining
by hyc＠symas.com 15 Dec '14

15 Dec '14

khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: > Full_Name: K. Ebrahimpour > Version: RE24 (commit dbc6741750de79b852ec9f728abb8b1425b6f03f) > OS: Ubuntu 14.04.1 > URL: https://gist.github.com/khosrow/cc6640cad9275a2cd041 > Submission from: (NULL) (205.211.133.128) > Finally, I'm running OpenLDAP 2.4.31 on Ubuntu Trusty, but was also able to > replicate this same error on OpenLDAP 2.4.28 on Ubuntu Precise. The current release is 2.4.40. For such old releases you should contact Ubuntu for support. -- -- 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#8005) crash when multiple olcDbURI are defined for chaining
by quanah＠zimbra.com 15 Dec '14

15 Dec '14

--On Monday, December 15, 2014 4:58 PM +0000 khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: > Finally, I'm running OpenLDAP 2.4.31 on Ubuntu Trusty, but was also able > to replicate this same error on OpenLDAP 2.4.28 on Ubuntu Precise. Both of those are years old, and known to have multitudes of issues. Please test using current RE24 code. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8005) crash when multiple olcDbURI are defined for chaining
by khosrow.ebrahimpour＠ssc-spc.gc.ca 15 Dec '14

15 Dec '14

Full_Name: K. Ebrahimpour Version: RE24 (commit dbc6741750de79b852ec9f728abb8b1425b6f03f) OS: Ubuntu 14.04.1 URL: https://gist.github.com/khosrow/cc6640cad9275a2cd041 Submission from: (NULL) (205.211.133.128) While trying to setup referral chaining in a multi-master setup, I can setup chaining to one of the masters without any problems. And I can perform a MOD operation that is then referral chased and performed on the master. However, when I define both masters the replica crashes when I do a MOD operation. Snippet of cn=config from the working example: dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbStartTLS: start starttls=yes olcDbIDAssertAuthzFrom: {0}* olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbURI: ldap://ldap-m1.example.com olcDbIDAssertBind: mode=self flags=prescriptive,proxauauthz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="cn=admin,dc=example,dc=com" credentials="secret" keepalive=0:0:0 starttls=yes tls_reqcert=allow If I change olcDbURI to either of the entries below, the replica server crashes * olcDbURI: "ldap://ldap-m1.example.com,ldap://ldap-m2.example.com" * olcDbURI: "ldap://ldap-m1.example.com ldap://ldap-m2.example.com" According to slapd-ldap(5), the URI list can be comma or space separated. I've turned on "args" and "trace" debugging to troubleshoot, but never get any errors in the logs. I only see an attempt to chase the referral followed by an immediate crash (see log snippet at the end of email). Finally, I'm running OpenLDAP 2.4.31 on Ubuntu Trusty, but was also able to replicate this same error on OpenLDAP 2.4.28 on Ubuntu Precise.

1 0

Re: (ITS#8003) segault with jpegPhoto > ~27KB and audit overlay
by hyc＠symas.com 15 Dec '14

15 Dec '14

Raffael Sahli wrote: > On 12.12.2014 09:08, Howard Chu wrote: >> public(a)raffaelsahli.com wrote: >>> Full_Name: Raffael Sahli >>> Version: 2.4.40 >>> OS: Ubuntu LTS 12.04 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (46.245.145.146) >>> >>> >>> slapd will crash if a database has the audit overlay enabled and the >>> attribute >>> jpegPhoto will be modified or added with data bigger than ~27KB. >>> >>> `/usr/local/libexec/slapd': free(): invalid next size (normal) >>> >>> Verified with custom builds on Ubuntu lts 12.04/14.04/Mint 14 and >>> bdb/mdb. >>> >>> Remove the audit overlay or migrate back to 2.4.39 solves the problem. Thanks, fixed now in master. -- -- 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#8003) segault with jpegPhoto > ~27KB and audit overlay
by public＠raffaelsahli.com 14 Dec '14

14 Dec '14

On 12.12.2014 09:08, Howard Chu wrote: > public(a)raffaelsahli.com wrote: >> Full_Name: Raffael Sahli >> Version: 2.4.40 >> OS: Ubuntu LTS 12.04 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (46.245.145.146) >> >> >> slapd will crash if a database has the audit overlay enabled and the >> attribute >> jpegPhoto will be modified or added with data bigger than ~27KB. >> >> `/usr/local/libexec/slapd': free(): invalid next size (normal) >> >> Verified with custom builds on Ubuntu lts 12.04/14.04/Mint 14 and >> bdb/mdb. >> >> Remove the audit overlay or migrate back to 2.4.39 solves the problem. >> >> > Please provide a sample slapd config that demonstrates the problem. > include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args database mdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" rootpw secret directory /usr/local/var/openldap-data index objectClass eq overlay auditlog auditlog /var/log/audit_slapd.log -- Raffael Sahli

1 0

Re: (ITS#8004) Simple Paged Control: Set 'size' in return control value to number of search results
by hyc＠symas.com 12 Dec '14

12 Dec '14

michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: > Submission from: (NULL) (79.227.182.177) > > > Feature request: > > http://tools.ietf.org/html/rfc2696#section-3 > > In the control returned to the client, the > size MAY be set to the server's estimate of the total number of > entries in the entire result set. > > So a client could evaluate this size value whether it's greater than 0 and take > this as indication how many search results would be returned (and e.g. display > it to the user). slapd doesn't know in advance how many results can be returned. It knows how many potential candidates were generated by index lookups, but this number may be much larger than the actual result set. In particular, the result set may be much smaller due to ACLs, as well as actual filter comparisons. It would be a security violation to disclose the existence of entries that the user is not permitted to see. Rejecting this request. -- -- 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#8004) Simple Paged Control: Set 'size' in return control value to number of search results
by michael＠stroeder.com 12 Dec '14

12 Dec '14

Full_Name: Version: OS: URL: Submission from: (NULL) (79.227.182.177) Feature request: http://tools.ietf.org/html/rfc2696#section-3 In the control returned to the client, the size MAY be set to the server's estimate of the total number of entries in the entire result set. So a client could evaluate this size value whether it's greater than 0 and take this as indication how many search results would be returned (and e.g. display it to the user). I'm asking myself whether slapo-noopsrch would be the right place for handling this. The no-op search control returns two distinct values for search results and search continuations though.

1 0

Re: (ITS#8003) segault with jpegPhoto > ~27KB and audit overlay
by hyc＠symas.com 12 Dec '14

12 Dec '14

public(a)raffaelsahli.com wrote: > Full_Name: Raffael Sahli > Version: 2.4.40 > OS: Ubuntu LTS 12.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (46.245.145.146) > > > slapd will crash if a database has the audit overlay enabled and the attribute > jpegPhoto will be modified or added with data bigger than ~27KB. > > `/usr/local/libexec/slapd': free(): invalid next size (normal) > > Verified with custom builds on Ubuntu lts 12.04/14.04/Mint 14 and bdb/mdb. > > Remove the audit overlay or migrate back to 2.4.39 solves the problem. > > Please provide a sample slapd config that demonstrates the problem. -- -- 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#8003) segault with jpegPhoto > ~27KB and audit overlay
by public＠raffaelsahli.com 11 Dec '14

11 Dec '14

Full_Name: Raffael Sahli Version: 2.4.40 OS: Ubuntu LTS 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (46.245.145.146) slapd will crash if a database has the audit overlay enabled and the attribute jpegPhoto will be modified or added with data bigger than ~27KB. `/usr/local/libexec/slapd': free(): invalid next size (normal) Verified with custom builds on Ubuntu lts 12.04/14.04/Mint 14 and bdb/mdb. Remove the audit overlay or migrate back to 2.4.39 solves the problem.

1 0

(ITS#8002) SSL fails with olcTLSVerifyClient=allow when ITS 7979 patch is applied
by rik.theys＠esat.kuleuven.be 11 Dec '14

11 Dec '14

Full_Name: Rik Theys Version: 2.4.40 OS: Fedora 21 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.58.253.57) Hi, After upgrading from Fedora 20 to 21 my client machine could no longer connect to our LDAP server. Fedora links openldap with nss for TLS. It throws the following error: TLS: certdb config: configDir='/etc/openldap/cacerts' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: cannot open certdb '/etc/openldap/cacerts', error -8018:Unknown PKCS #11 error. TLS: loaded CA certificate file /etc/openldap/cacerts/a9b3780c.0 from CA certificate directory /etc/openldap/cacerts. TLS: loaded CA certificate file /etc/openldap/cacerts/f4033bb2.0 from CA certificate directory /etc/openldap/cacerts. TLS: skipping 'cacert.pem' - filename does not have expected format (certificate hash with numeric suffix) TLS: skipping 'esat.pem' - filename does not have expected format (certificate hash with numeric suffix) TLS: certificate [CN=wheezy-test.esat.kuleuven.be,OU=ESAT,O=KU Leuven,ST=Leuven,C=BE] is valid TLS: error: connect - force handshake failure: errno 0 - moznss error -12256 TLS: can't connect: TLS error -12256:SSL received a malformed Certificate Request handshake message.. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) I downgraded to fedora package 2.4.40-1.fc21 which did not have this bug. The only difference between 2.4.40-1.fc21 and 2.4.40-2.fc21 is a backported patch for ITS #7979 which adds TLS 1+ support. I tried to reproduce this on a test machine and was initially unable to reproduce it there. Comparing the config of the test machine with our failing LDAP servers only showed a difference for the olcTLSVerifyClient setting. When the LDAP server does not have 'olcTLSVerifyClient: allow' in its configuration, it works. Once I set this parameter in the server configuration, the error above appears and LDAP connections are broken. The patch looks OK so maybe there's something wrong when openldap uses a higher TLS version and the bug it to be found there? I've also filed this bug in the fedora bug tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1172638 Regards, Rik

1 0

Re: (ITS#7977) Supported PBKDF2-SHA256 and PBKDF2-SHA512
by luca.bruno＠rocket-internet.de 11 Dec '14

11 Dec '14

> with a corresponding IPR statement as outlined in > our Contributors guidelines. I was (wrongly) assuming that the explicit "Signed-off-by" line in each patch was enough to express this from my side. Just to be more explicit, here is the IPR statement for my part of the patch: """ The attached patch is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Luca Bruno, on behalf of "Rocket Internet AG". By virtue of my employment agreement with "Rocket Internet AG", I have assigned my rights and interest in this work to "Rocket Internet AG". "Rocket Internet AG" has not assigned rights and/or interest in this work to any party. I, Luca Bruno am authorized by "Rocket Internet AG", my employer, to release this work under the following terms. "Rocket Internet AG" hereby places the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. """ Cheers, Luca PS. I would suggest to explicitly CC third-parties when you are missing IPR info, as I was not aware that this ticket was waiting for input on my side. -- Luca Bruno (kaeso) Security Engineer Rocket Internet AG -> GPG Key ID: 0x4F3BBEBF

1 0

Re: (ITS#8001) Segmentation Fault in ldap_sync_*
by hyc＠symas.com 10 Dec '14

10 Dec '14

alexey(a)kireyev.name wrote: > Full_Name: Alexey Kireyev > Version: 2.4.40 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (98.118.88.65) > > > If not all fields in ldap_sync_t manually set after ldap_sync_initialize, then > any following calls might (and most probably will) ends in segmentation fault. > > Reason: ldap_sync_initialize doesn't zeroed newly allocated structure (it does > it for pre-existing, though, which is wrong by itself in my view) Thanks, you're right. fixed in master. > > > > > -------------------------------------------------------------------------------------------------------- > > >>From 01149a2eba9f463261d88e5a1ce43e19c4a323cf Mon Sep 17 00:00:00 2001 > From: Alexey Kireyev <alexey(a)kireyev.name> > Date: Wed, 10 Dec 2014 14:37:16 -0500 > Subject: [PATCH] Newly allocated ldap_sync_t has to be zero out > > --- > libraries/libldap/ldap_sync.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/libraries/libldap/ldap_sync.c b/libraries/libldap/ldap_sync.c > index e573c3b..e79153f 100644 > --- a/libraries/libldap/ldap_sync.c > +++ b/libraries/libldap/ldap_sync.c > @@ -64,11 +64,10 @@ ldap_sync_initialize( ldap_sync_t *ls_in )D%D > if ( ls == NULL ) { > return NULL; > } > - > - } else { > - memset( ls, 0, sizeof( ldap_sync_t ) ); > } > > + memset( ls, 0, sizeof( ldap_sync_t ) ); > + > ls->ls_scope = LDAP_SCOPE_SUBTREE; > ls->ls_timeout = -1; > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7998) no-return-in-nonvoid-function noopsrch.c:145
by michael＠stroeder.com 10 Dec '14

10 Dec '14

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> As I read noopsrch_response there's a else {} clause missing. >> But I'm not sure. > > Yes, but not important. Unfortunately the build is blocked on openSUSE build system because of this. There may be a way to work around it but I don't know how. Ciao, Michael.

1 0

Re: (ITS#8000) Warnings building contrib overlay passwd/sha2
by hyc＠symas.com 10 Dec '14

10 Dec '14

michael(a)stroeder.com wrote: > Full_Name: > Version: RE24 > OS: > URL: > Submission from: (NULL) (79.227.174.182) > > > HI! > > I'm trying to package passwd/sha2 for openSUSE. > The default compiler options in their build system results in these warnings: Fixed in master. The note about compilers breaking this code is spurious. Any compiler that failed to properly compile the previous code would itself be broken. > > [ 193s] + CFLAGS='-fomit-frame-pointer -fmessage-length=0 -grecord-gcc-switches > -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables > -fasynchronous-unwind-tables -g -Wno-format-extra-args -fno-strict-aliasing' > [ 193s] + make -j4 sysconfdir=/etc/openldap libdir=/usr/lib > libexecdir=/usr/lib > [ 193s] ../../../../libtool --mode=compile gcc -g -O2 -Wall > -I..%2.%./../../include -I../../../../include -I../../../../servers/slapd -c > slapd-sha2.c > [ 193s] ../../../../libtool --mode=compile gcc -g -O2 -Wall > -I../../../../include -I../../../../include -I../../../../servers/slapd -c > sha2.c > [ 193s] mkdir .libs > [ 193s] mkdir .libs > [ 193s] mkdir: cannot create directory '.libs': File exists > [ 193s] gcc -g -O2 -Wall -I../../../../include -I../../../../include > -I../../../../servers/slapd -c sha2.c -fPIC -DPIC -o .libs/sha2.o > [ 193s] gcc -g -O2 -Wall -I../../../../include -I../../../../include > -I../../../../servers/slapd -c slapd-sha2.c -fPIC -DPIC -o .libs/slapd-sha2.o > [ 193s] sha2.c: In function 'SHA256_Final': > [ 193s] sha2.c:608:3: warning: dereferencing type-punned pointer will break > strict-aliasing rules [-Wstrict-aliasing] > [ 193s] *(sha2_word64*)&context->buffer[SHA256_SHORT_BLOCK_LENGTH] = > context->bitcount; > [ 193s] ^ > [ 193s] sha2.c: In function 'SHA512_Last': > [ 193s] sha2.c:925:2: warning: dereferencing type-punned pointer will break > strict-aliasing rules [-Wstrict-aliasing] > [ 193s] *(sha2_word64*)&context->buffer[SHA512_SHORT_BLOCK_LENGTH] = > context->bitcount[1]; > [ 193s] ^ > [ 193s] sha2.c:926:2: warning: dereferencing type-punned pointer will break > strict-aliasing rules [-Wstrict-aliasing] > [ 193s] *(sha2_word64*)&context->buffer[SHA512_SHORT_BLOCK_LENGTH+8] = > context->bitcount[0]; > [ 193s] ^ > [ 193s] gcc -g -O2 -Wall -I../../../../include -I../../../../include > -I../../../../servers/slapd -c slapd-sha2.c -o slapd-sha2.o >/dev/null > 2>&1 > [ 193s] gcc -g -O2 -Wall -I../../../../include -I../../../../include > -I../../../../servers/slapd -c sha2.c -o sha2.o >/dev/null 2>&1 > [ 194s] ../../../../libtool --mode=link gcc -g -O2 -Wall -version-info 0:0:0 \ > [ 194s] -rpath /usr/lib/openldap -module -o pw-sha2.la slapd-sha2.lo sha2.lo > ../../../../libraries/libldap_r/libldap_r.la > ../../../../libraries/liblber/liblber.la > [ 194s] cc -shared .libs/slapd-sha2.o .libs/sha2.o -Wl,--rpath > -Wl,/home/abuild/rpmbuild/BUILD/openldap-2.4.40/libraries/libldap_r/.libs > -Wl,--rpath -Wl,/home/abuild/rpmbuild/BUILD/openldap-2.4.40/libraries/liblber/.libs > -L/home/abuild/rpmbuild/BUILD/openldap-2.4.40/libraries/liblber/.libs > ../../../../libraries/libldap_r/.libs/libldap_r.so > ../../../../libraries/liblber/.libs/liblber.so -Wl,-soname -Wl,pw-sha2.so.0 -o > .libs/pw-sha2.so.0.0.0 > [ 194s] (cd .libs && rm -f pw-sha2.so.0 && ln -s > pw-sha2.so.0.0.0 pw-sha2.so.0) > [ 194s] (cd .libs && rm -f pw-sha2.so && ln -s pw-sha2.so.0.0.0 > pw-sha2.so) > [ 194s] ar cru .libs/pw-sha2.a slapd-sha2.o sha2.o > [ 194s] ranlib .libs/pw-sha2.a > [ 194s] creating pw-sha2.la > > > Overall RPM build fails with: > > [ 262s] I: Program is likely to break with new gcc. Try -fno-strict-aliasing. > [ 262s] W: openldap2 strict-aliasing-punning sha2.c:608, 925, 926 > > -- -- 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#7998) no-return-in-nonvoid-function noopsrch.c:145
by hyc＠symas.com 10 Dec '14

10 Dec '14

michael(a)stroeder.com wrote: > As I read noopsrch_response there's a else {} clause missing. > But I'm not sure. Yes, but not important. -- -- 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#7998) no-return-in-nonvoid-function noopsrch.c:145
by hyc＠symas.com 10 Dec '14

10 Dec '14

michael(a)stroeder.com wrote: > Full_Name: > Version: RE24 > OS: > URL: > Submission from: (NULL) (79.227.174.182) > > > Building slapo- (contrib/) with strict warnings results in: > > no-return-in-nonvoid-function noopsrch.c:145 > > Fixed in master -- -- 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#7997) no-return-in-nonvoid-function dupent.c:367
by hyc＠symas.com 10 Dec '14

10 Dec '14

michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: > Submission from: (NULL) (79.227.174.182) > > > Building slapo-dupent (contrib/) with strict warnings results in: > > no-return-in-nonvoid-function dupent.c:367 > > > Fixed in master -- -- 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#8001) Segmentation Fault in ldap_sync_*
by alexey＠kireyev.name 10 Dec '14

10 Dec '14

Full_Name: Alexey Kireyev Version: 2.4.40 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (98.118.88.65) If not all fields in ldap_sync_t manually set after ldap_sync_initialize, then any following calls might (and most probably will) ends in segmentation fault. Reason: ldap_sync_initialize doesn't zeroed newly allocated structure (it does it for pre-existing, though, which is wrong by itself in my view) -------------------------------------------------------------------------------------------------------- >From 01149a2eba9f463261d88e5a1ce43e19c4a323cf Mon Sep 17 00:00:00 2001 From: Alexey Kireyev <alexey(a)kireyev.name> Date: Wed, 10 Dec 2014 14:37:16 -0500 Subject: [PATCH] Newly allocated ldap_sync_t has to be zero out --- libraries/libldap/ldap_sync.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/libraries/libldap/ldap_sync.c b/libraries/libldap/ldap_sync.c index e573c3b..e79153f 100644 --- a/libraries/libldap/ldap_sync.c +++ b/libraries/libldap/ldap_sync.c @@ -64,11 +64,10 @@ ldap_sync_initialize( ldap_sync_t *ls_in )D%D if ( ls == NULL ) { return NULL; } - - } else { - memset( ls, 0, sizeof( ldap_sync_t ) ); } + memset( ls, 0, sizeof( ldap_sync_t ) ); + ls->ls_scope = LDAP_SCOPE_SUBTREE; ls->ls_timeout = -1; -- 1.9.1 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 Alexey Kireyev alexey(a)kireyev.name. I have not assigned rights and/or interest in this work to any party. I, Alexey Kireyev, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs