openldap-bugs May 2018

openldap-bugs@openldap.org

18 participants
45 discussions

Re: (ITS#8846) Patch to introduce new LDAP option to ignore hostname checking while verifying certificates in TLS mode
by sudhir.singam＠gmail.com 16 May '18

16 May '18

--000000000000ef2539056c5164f5 Content-Type: text/plain; charset="UTF-8" Hi, Reference to SOAP, where we have the option of SOAP_SSL_SKIP_HOST_CHECK https://www.genivia.com/doc/soapdoc2.html --000000000000ef2539056c5164f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi,<br><br>Reference to SOAP, where we have the option of= =C2=A0=C2=A0<span style=3D"color:rgb(0,0,0);font-family:inconsolatamedium,m= onospace,serif;font-size:14px;font-style:normal;font-variant-ligatures:norm= al;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-alig= n:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:= 0px;background-color:rgb(255,255,238);text-decoration-style:initial;text-de= coration-color:initial;float:none;display:inline">SOAP_SSL_SKIP_HOST_CHECK<= /span> <br><br><a href=3D"https://www.genivia.com/doc/soapdoc2.html">https://www.g= enivia.com/doc/soapdoc2.html</a><div><br></div><div><br><div><br></div></di= v></div> --000000000000ef2539056c5164f5--

1 0

Re: (ITS#8846) Patch to introduce new LDAP option to ignore hostname checking while verifying certificates in TLS mode
by sudhir.singam＠gmail.com 15 May '18

15 May '18

Hi, Thanks for the reply. For DNS use case, " Operator may make certificates only once in a while (as they cost), and at that point it is not certain that all IP addresses are known. They likely might now only know the current literal address, but the numeric address can change in the lifetime of the certificate Changing /etc/hosts is not possible, as this configuration is not supported for operators. " Still we feel configuration is a good thing, i.e., if one explicitly wants to allow a connection despite of warnings (i.e., has analysed the warning to be a false positive), that should still be acceptable, and not unilaterally bad. Also, one needs to be able to distinguish between =E2=80=9Cnormal=E2=80=9D network (open for everyone), and an operat= or-internal network: requirements for these two are different, and if one library is to serve both, it should be able to handle (=3Dbeing configurable) both use cases. System configuration setup is anyway also done by a human, so if someone wants explicitly disable some checks for automated clients, it is logically similar to a human pressing some =E2=80=9Cacknowledge=E2=80=9D= button. And i don't think the browsers are going to remove it, at most they may move this option to settings. I think nobody wants a monolithic browser that cannot be tailored for user needs, which anyway cannot be anticipated by the browser maker. Whether it is interactive or configuration based does not matter as long as the configuration is there somehow. And the same logic applies also for LDAP ;) But then openLDAP or openSSL is already providing options to ignore some of the certificate errors, for example, i can set SSL verify call back function via LDAP options to ignore certificate CRL errors and continue the connection. So i still wonder why it is not possible in this case and feel it has to be user configurable. Regards, Sudhir, NOKIA

1 0

(ITS#8846) Patch to introduce new LDAP option to ignore hostname checking while verifying certificates in TLS mode
by sudhir.singam＠gmail.com 15 May '18

15 May '18

--000000000000d6fc43056c4ba325 Content-Type: text/plain; charset="UTF-8" Hi, --000000000000d6fc43056c4ba325 Content-Type: text/html; charset="UTF-8" <div dir="ltr">Hi,</div> --000000000000d6fc43056c4ba325--

1 0

Re: (ITS#8854) Memory leak in modify transaction case
by quanah＠symas.com 14 May '18

14 May '18

--On Monday, May 14, 2018 2:56 PM +0000 verchaswa(a)mavenir.com wrote: > Full_Name: Verchaswa Sharma > Version: 2.4.11 2.4.11 is nearly 10 years old. Please use a current release of OpenLDAP. This ITS will be closed. If you find the issues exists in the current 2.4.46 release, then follow up and the ITS will be reopened. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8855) Memory leak in modify transaction case
by verchaswa.sharma＠mavenir.com 14 May '18

14 May '18

Full_Name: Verchaswa Sharma Version: 2.4.11 OS: Windriver x86_64 GNU/Linux URL: Submission from: (NULL) (62.168.56.1) Hi, While testing modify for transactions, we observed memory leak in libldap. We ran memtrace found following memory leak. + 27605 1526029632 0x168b0008 4060 @0 memtrace_newhook(void const*, unsigned long) [0x5b1b3d] @1 MallocHook::InvokeNewHookSlow(void const*, unsigned long) [0x7f1cb61648e1] @2 malloc [0x7f1cb616748a] @3 ber_memalloc_x [0x5adf24] @4 ber_realloc [0x5accf4] @5 ber_write [0x5acd82] @6 ber_put_tag [0x5aba2a] @7 ber_put_int_or_enum [0x5abbbf] @8 ber_printf [0x5ac89d] @9 ldap_modify_ext [0x6c46e4] --------------- + 4167 1526297517 0x2b7a9048 136 @0 memtrace_newhook(void const*, unsigned long) [0x5b1b3d] @1 MallocHook::InvokeNewHookSlow(void const*, unsigned long) [0x7f11bb68b8e1] @2 tc_calloc [0x7f11bb68ebf9] @3 ber_memcalloc_x [0x5adf94] @4 ldap_send_server_request [0x6cbfa5] @5 ldap_send_initial_request [0x6cc23d] @6 ldap_modify_ext [0x6c47de] ---------------- + 4169 1526297517 0x2c4672e8 15 @0 memtrace_newhook(void const*, unsigned long) [0x5b1b3d] @1 MallocHook::InvokeNewHookSlow(void const*, unsigned long) [0x7f11bb68b8e1] @2 malloc [0x7f11bb68e48a] @3 ber_memalloc_x [0x5adf24] @4 ber_strdup_x [0x5ae5c2] @5 ldap_control_create [0x6c3d18] ---------------------- + 4171 1526297517 0x2aa8c828 80 @0 memtrace_newhook(void const*, unsigned long) [0x5b1b3d] @1 MallocHook::InvokeNewHookSlow(void const*, unsigned long) [0x7f11bb68b8e1] @2 tc_calloc [0x7f11bb68ebf9] @3 ber_memcalloc_x [0x5adf94] @4 ber_alloc_t [0x5acff1] @5 ldap_alloc_ber_with_options [0x6cb7cf] @6 ldap_modify_ext [0x6c4687] ---------------------------

1 0

(ITS#8854) Memory leak in modify transaction case
by verchaswa＠mavenir.com 14 May '18

14 May '18

Full_Name: Verchaswa Sharma Version: 2.4.11 OS: Windriver x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.168.56.1) Hi, While testing modify for transactions, we observed memory leak in libldap. We ran memtrace found following memory leak. + 27605 1526029632 0x168b0008 4060 @0 memtrace_newhook(void const*, unsigned long) [0x5b1b3d] @1 MallocHook::InvokeNewHookSlow(void const*, unsigned long) [0x7f1cb61648e1] @2 malloc [0x7f1cb616748a] @3 ber_memalloc_x [0x5adf24] @4 ber_realloc [0x5accf4] @5 ber_write [0x5acd82] @6 ber_put_tag [0x5aba2a] @7 ber_put_int_or_enum [0x5abbbf] @8 ber_printf [0x5ac89d] @9 ldap_modify_ext [0x6c46e4] --------------- + 4167 1526297517 0x2b7a9048 136 @0 memtrace_newhook(void const*, unsigned long) [0x5b1b3d] @1 MallocHook::InvokeNewHookSlow(void const*, unsigned long) [0x7f11bb68b8e1] @2 tc_calloc [0x7f11bb68ebf9] @3 ber_memcalloc_x [0x5adf94] @4 ldap_send_server_request [0x6cbfa5] @5 ldap_send_initial_request [0x6cc23d] @6 ldap_modify_ext [0x6c47de] ---------------- + 4169 1526297517 0x2c4672e8 15 @0 memtrace_newhook(void const*, unsigned long) [0x5b1b3d] @1 MallocHook::InvokeNewHookSlow(void const*, unsigned long) [0x7f11bb68b8e1] @2 malloc [0x7f11bb68e48a] @3 ber_memalloc_x [0x5adf24] @4 ber_strdup_x [0x5ae5c2] @5 ldap_control_create [0x6c3d18] ---------------------- + 4171 1526297517 0x2aa8c828 80 @0 memtrace_newhook(void const*, unsigned long) [0x5b1b3d] @1 MallocHook::InvokeNewHookSlow(void const*, unsigned long) [0x7f11bb68b8e1] @2 tc_calloc [0x7f11bb68ebf9] @3 ber_memcalloc_x [0x5adf94] @4 ber_alloc_t [0x5acff1] @5 ldap_alloc_ber_with_options [0x6cb7cf] @6 ldap_modify_ext [0x6c4687] ---------------------------

1 0

Re: (ITS#8846) Patch to introduce new LDAP option to ignore hostname checking while verifying certificates in TLS mode
by michael＠stroeder.com 14 May '18

14 May '18

> c) DNS server is not set up I.e., the certificate could be issued > with a name like “netact.operator”, but we’d be using 10.2.3.7, and > DNS has not been setup in the operator internal network > > But what we feel is that there should be an option to be chosen by > user to either ignore or enable hostname checking. If you're using ldaps://10.2.3.7 for connecting without DNS resolving you could add a subjectAltName extension to your server cert containing this particular IP address. That's basically just another GeneralName type. You could also tweak your local /etc/hosts (preferrably with decent config mgt.) to correctly map FQDN "netact.operator" to the IP address. > Already we know > that HTTP clients, for example, browsers provide such option to user > and it's up to the user that whether to continue communication to the > server or not, if hostname mismatch occurs. Note that web browsers are driven interactively by users whereas LDAP clients are most times systems without direct user interaction. In the interactive case you simply delegate the informed trust decision to the user which is a bad thing to do anyway. Therefore web browsers will also limit this functionality in the not so far future. Ciao, Michael. P.S.: Due to MIME processing deficiencies of the ITS your messages are displayed base64-encoded and therefore hard to read: https://www.openldap.org/its/index.cgi?findid=8846#followup4

1 0

RE: (ITS#8846) Patch to introduce new LDAP option to ignore hostname checking while verifying certificates in TLS mode
by sudhir.singam＠nokia.com 13 May '18

13 May '18

SGksDQoNCktpbmRseSBwbGVhc2UgcmVwbHkuDQoNClJlZ2FyZHMsDQpTdWRoaXIgU2luZ2FtDQoN CkRFTElWRVJJTkcgQkVTVC1JTi1DTEFTUyBQTEFURk9STSBpcyBvdXIgdmlzaW9uDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTaW5nYW0sIFN1ZGhpciAoTm9raWEgLSBJTi9C YW5nYWxvcmUpIA0KU2VudDogV2VkbmVzZGF5LCBNYXkgMDksIDIwMTggMTE6MjYgQU0NClRvOiAn SG93YXJkIENodScgPGh5Y0BzeW1hcy5jb20+OyAnb3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZycg PG9wZW5sZGFwLWl0c0BPcGVuTERBUC5vcmc+DQpTdWJqZWN0OiBSRTogKElUUyM4ODQ2KSBQYXRj aCB0byBpbnRyb2R1Y2UgbmV3IExEQVAgb3B0aW9uIHRvIGlnbm9yZSBob3N0bmFtZSBjaGVja2lu ZyB3aGlsZSB2ZXJpZnlpbmcgY2VydGlmaWNhdGVzIGluIFRMUyBtb2RlDQoNCkhpLA0KDQpUaGFu a3MgZm9yIHlvdXIgcmVzcG9uc2UuDQoNCkJhc2ljYWxseSBvdXIgdXNlIGNhc2UgY2FuIGJlIGJl bG93IG9yIGFueSBzaW1pbGFyIG9uZSB3aGVyZSB3ZSB3YW50IHRvIGRpc2FibGUgaG9zdG5hbWUg Y2hlY2tpbmcuDQoNCmEpCVdlIHdhbnQgdXNlIHRoZSBzYW1lIGNlcnRzIGZyb20gbXVsdGkgZG9t YWlucw0KYikJV2Ugd2FudCB1c2UgdGhlIHNhbWUgY2VydHMgZm9yIGFsbCBzdWIgZG9tYWlucyB1 bmRlciBhIG1haW4gZG9tYWluLg0KYykJRE5TIHNlcnZlciBpcyBub3Qgc2V0IHVwICAgSS5lLiwg dGhlIGNlcnRpZmljYXRlIGNvdWxkIGJlIGlzc3VlZCB3aXRoIGEgbmFtZSBsaWtlIOKAnG5ldGFj dC5vcGVyYXRvcuKAnSwgYnV0IHdl4oCZZCBiZSB1c2luZyAxMC4yLjMuNywgYW5kIEROUyBoYXMg bm90IGJlZW4gc2V0dXAgaW4gdGhlIG9wZXJhdG9yIGludGVybmFsIG5ldHdvcmsNCg0KQnV0IHdo YXQgd2UgZmVlbCBpcyB0aGF0IHRoZXJlIHNob3VsZCBiZSBhbiBvcHRpb24gdG8gYmUgY2hvc2Vu IGJ5IHVzZXIgdG8gZWl0aGVyIGlnbm9yZSBvciBlbmFibGUgaG9zdG5hbWUgY2hlY2tpbmcuIEFs cmVhZHkgd2Uga25vdyB0aGF0IEhUVFAgY2xpZW50cywgZm9yIGV4YW1wbGUsIGJyb3dzZXJzIHBy b3ZpZGUgc3VjaCBvcHRpb24gdG8gdXNlciBhbmQgaXQncyB1cCB0byB0aGUgdXNlciB0aGF0IHdo ZXRoZXIgdG8gY29udGludWUgY29tbXVuaWNhdGlvbiB0byB0aGUgc2VydmVyIG9yIG5vdCwgaWYg aG9zdG5hbWUgbWlzbWF0Y2ggb2NjdXJzLg0KDQpSRkMgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmMv cmZjMjgxOC50eHQgKGZvciBIVFRQKSBzYXlzIGJlbG93LCB3aGljaCBtZWFucyBmb3IgaW50ZXJh Y3RpdmUgb3IgQVVUT01BVEVEIGNsaWVudHMgb3B0aW9uIHNob3VsZCBiZSBwcm92aWRlZC4NCg0K IiAgIElmIHRoZSBob3N0bmFtZSBkb2VzIG5vdCBtYXRjaCB0aGUgaWRlbnRpdHkgaW4gdGhlIGNl cnRpZmljYXRlLCB1c2VyDQogICBvcmllbnRlZCBjbGllbnRzIE1VU1QgZWl0aGVyIG5vdGlmeSB0 aGUgdXNlciAoY2xpZW50cyBNQVkgZ2l2ZSB0aGUNCiAgIHVzZXIgdGhlIG9wcG9ydHVuaXR5IHRv IGNvbnRpbnVlIHdpdGggdGhlIGNvbm5lY3Rpb24gaW4gYW55IGNhc2UpIG9yDQogICB0ZXJtaW5h dGUgdGhlIGNvbm5lY3Rpb24gd2l0aCBhIGJhZCBjZXJ0aWZpY2F0ZSBlcnJvci4gQXV0b21hdGVk DQogICBjbGllbnRzIE1VU1QgbG9nIHRoZSBlcnJvciB0byBhbiBhcHByb3ByaWF0ZSBhdWRpdCBs b2cgKGlmIGF2YWlsYWJsZSkNCiAgIGFuZCBTSE9VTEQgdGVybWluYXRlIHRoZSBjb25uZWN0aW9u ICh3aXRoIGEgYmFkIGNlcnRpZmljYXRlIGVycm9yKS4NCiAgIEF1dG9tYXRlZCBjbGllbnRzIE1B WSBwcm92aWRlIGEgY29uZmlndXJhdGlvbiBzZXR0aW5nIHRoYXQgZGlzYWJsZXMNCiAgIHRoaXMg Y2hlY2ssIGJ1dCBNVVNUIHByb3ZpZGUgYSBzZXR0aW5nIHdoaWNoIGVuYWJsZXMgaXQuDQoiDQoN ClJGQyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDUxMyAoTERBUCkgc2F5cyBiZWxv dywgdGhhdCBBVVRPTUFURUQgY2xpZW50IHNob3VsZCBsb2cgZXJyb3IgYnV0IG5vdCBwcm92aWRl IGFueSBjb25maWd1cmFibGUgb3B0aW9uLg0KDQrigJwNCg0KSWYgdGhlIHNlcnZlciBpZGVudGl0 eSBjaGVjayBmYWlscywgdXNlci1vcmllbnRlZCBjbGllbnRzIFNIT1VMRA0KICAgZWl0aGVyIG5v dGlmeSB0aGUgdXNlciAoY2xpZW50cyBtYXkgZ2l2ZSB0aGUgdXNlciB0aGUgb3Bwb3J0dW5pdHkg dG8NCiAgIGNvbnRpbnVlIHdpdGggdGhlIExEQVAgc2Vzc2lvbiBpbiB0aGlzIGNhc2UpIG9yIGNs b3NlIHRoZSB0cmFuc3BvcnQNCiAgIGNvbm5lY3Rpb24gYW5kIGluZGljYXRlIHRoYXQgdGhlIHNl cnZlcidzIGlkZW50aXR5IGlzIHN1c3BlY3QuDQogICBBdXRvbWF0ZWQgY2xpZW50cyBTSE9VTEQg Y2xvc2UgdGhlIHRyYW5zcG9ydCBjb25uZWN0aW9uIGFuZCB0aGVuDQogICByZXR1cm4gb3IgbG9n IGFuIGVycm9yIGluZGljYXRpbmcgdGhhdCB0aGUgc2VydmVyJ3MgaWRlbnRpdHkgaXMNCiAgIHN1 c3BlY3Qgb3IgYm90aC4NCuKAnA0KDQpOb3Qgc3VyZSBob3cgdGhlIEFVVE9NQVRFRCBjbGllbnRz IGRpZmZlciBmb3IgSFRUUCBvciBMREFQLg0KDQpTbyBJIHdvdWxkIGxpa2UgdG8ga25vdyB3aHkg dGhpcyBpcyBub3QgaW1wbGVtZW50ZWQgb3IgY2FuJ3QgYmUgaW1wbGVtZW50ZWQgZm9yIG9wZW5M REFQLg0KDQo=

1 0

Re: (ITS#8853) back-mdb broken on GNU/kFreeBSD
by ryan＠nardis.ca 12 May '18

12 May '18

Never mind. This works for me on a local VM. The build server has a bunch of outdated packages so I'm going to blame that build environment unless proven otherwise. Closing the ITS; sorry for the noise.

1 0

(ITS#8853) back-mdb broken on GNU/kFreeBSD
by ryan＠openldap.org 12 May '18

12 May '18

Full_Name: Ryan Tandy Version: 2.4.46 OS: Debian URL: Submission from: (NULL) (70.66.128.207) Submitted by: ryan On Debian GNU/kFreeBSD (Debian with GNU userland and FreeBSD kernel), liblmdb and back-mdb compile but slapd apparently fails to start. Build log: https://buildd.debian.org/status/fetch.php?pkg=openldap&arch=kfreebsd-amd64… >>>>> Executing all LDAP tests for mdb >>>>> Starting test000-rootdse for mdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ../../../tests/scripts/test000-rootdse: 66: kill: No such process ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> Test failed >>>>> test000-rootdse failed for mdb This is a low priority issue. Just filing the ITS for tracking. More details to come once I find time to install a VM and compile/run it myself. Probably similar to ITS#8554. Debian bug reference: https://bugs.debian.org/898070

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2018