openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

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

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

12 Sep '15

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... 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. 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)".

1 0

(ITS#8243) LMDB Makefile bug
by jiayq＠eecs.berkeley.edu 12 Sep '15

12 Sep '15

Full_Name: Yangqing Jia Version: OS: Ubuntu 12.04 URL: Submission from: (NULL) (2601:646:8f00:2700:ac83:6009:7765:c6b0) In the Makefile of LMDB, the installation part reads as follows: install: $(ILIBS) $(IPROGS) $(IHDRS) for f in $(IPROGS); do cp $$f $(DESTDIR)$(prefix)/bin; done for f in $(ILIBS); do cp $$f $(DESTDIR)$(prefix)/lib; done for f in $(IHD%2); do cp $$f $(DESTDIR)$(prefix)/include; done for f in $(IDOCS); do cp $$f $(DESTDIR)$(prefix)/man/man1; done This usually works OK, but it silently asumes that $(DESTDIR)$(prefix)/bin and other folders exist. While it works in most cases, if the folders do not exist, what follows is that the installation script generates FILES instead of FOLDERS named bin, lib, include and man1 respectively. We should add "mkdir -p" commands in the installation part to fix this.

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: > Our patch response was too hasty. There is no OpenLDAP bug here, the real > issue is production binaries being built with asserts enabled instead of > compiling with -DNDEBUG. That's an issue for packagers and distros to resolve. > Closing this ITS, not an OpenLDAP bug. I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not help. slapd still crashes when hitting the assert. Ciao, Michael.

1 0

Re: (ITS#7964) overlay rwm escape issue with more the 9 rules / rewrite statements
by michael＠stroeder.com 12 Sep '15

12 Sep '15

This is a cryptographically signed message in MIME format. --------------ms030300010006010903020301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ryan Tandy wrote: > Fixed in git master by removing the extra escaping on insert. You will = have to > adjust your rules to use a single backslash instead of two. 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. Ciao, Michael. --------------ms030300010006010903020301 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 MDkxMjEyMzg0NFowLwYJKoZIhvcNAQkEMSIEIDrXZa1NywG8SrP5ntFoYlltABMT8tTiZXDf 2VaTDJRiMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQAeCC2CW5txoCJMgggs UcEJA2eZPOXbq3XU1XrDvO6tsBacNPuuIvJ/rbcjBYgwy/aTcQfbgeLhgNKeigtYtGIMMAo2 lKohLrccMl7ZlQ+ysZDu8gzK715y9z+SZqsz6/82zK2o1UBRcZpKKMDJjV3fUFc+AoS9mPo5 Vz/P4an5x5YckvOaHb6a7El6gvEbTRbVTwPJldlSo6PIcGDf2Jk/vEDDmBS59VK/+mgaHp7R JwYHYQmSxCYBWuR9JBAB0maoQMJf9tEUMh9CQiwj8CVko92ov6xIOHRfDXOuCDZZ4tdjOPDC lqNaoruOVzuULGhzW9wo5oabo19dgb4pOuI6AAAAAAAA --------------ms030300010006010903020301--

1 0

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

12 Sep '15

denis.andzakovic(a)security-assessment.com wrote: > Full_Name: Denis Andzakovic > Version: 2.4.42 > OS: Debian 8 > URL: > Submission from: (NULL) (2402:6000:110:a01:743b:8319:1f96:bd89) > > > OpenLDAP ber_get_next Denial of Service > Affected Versions: OpenLDAP <= 2.4.42 > +----------+ > | Solution | > +----------+ > Ensure that data received from untrusted sources is not able to trigger > conditions resulting in the server crashing. In this specific instance, the > NDEBUG macro should be defined before the inclusion of assert.h by default, > requiring a specific compile time alteration to enable debug. Our patch response was too hasty. There is no OpenLDAP bug here, the real issue is production binaries being built with asserts enabled instead of compiling with -DNDEBUG. That's an issue for packagers and distros to resolve. Closing this ITS, not an OpenLDAP bug. -- -- 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
by hyc＠symas.com 11 Sep '15

11 Sep '15

michael(a)stroeder.com wrote: > Hmm...wouldn't this ITS justify some quick security release 2.4.43? For the umpteenth time - the Project only considers unintended information disclosures or remote code execution flaws as security issues. Neither applies 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs