- openldap-bugs - openldap.org

(ITS#9084) Build issue when slaps is not included
by aixtools＠felt.demon.nl 18 Sep '19

18 Sep '19

Full_Name: Michael Felt Version: 2.4.48 OS: AIX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.104.126.147) Build of 2.4.46 proceeds with no issue. When using the same command to build 2.4.48 the build stops with an undefined variable error: root@x066:[/data/prj/aixtools/src]grep LDAP_OPT_X_TLS *46/* *48/* openldap-2.4.46/CHANGES: Added libldap LDAP_OPT_X_TLS_PACKAGE (ITS#6969) openldap-2.4.48/CHANGES: Added libldap LDAP_OPT_X_TLS_PACKAGE (ITS#6969) root@x066:[/data/prj/aixtools/src]find *46 *48 | xargs grep LDAP_OPT_X_TLS_ECNAME openldap-2.4.48/include/ldap.h:#define LDAP_OPT_X_TLS_ECNAME 0x6012 openldap-2.4.48/libraries/libldap/tls2.c: case LDAP_OPT_X_TLS_ECNAME: openldap-2.4.48/libraries/libldap/tls2.c: case LDAP_OPT_X_TLS_ECNAME: openldap-2.4.48/servers/slapd/bconfig.c: case CFG_TLS_ECNAME: flag = LDAP_OPT_X_TLS_ECNAME; break; >From above, it appears that LDAP_OPT_X_TLS_ECNAME should be defined, but I question that as I get the following error when compiling... Entering subdirectory libldap make[2]: Entering directory '/data/prj/aixtools/static/openldap-2.4.48/libraries/libldap' /bin/sh ../../libtool --mode=compile xlc_r -I/opt/include -O2 -qmaxmem=-1 -I../../include -I../../../../src/openldap-2.4.48/include -I/opt/include -DLDAP_LIBRARY -c ../../../../src/openldap-2.4.48/libraries/libldap/tls2.c xlc_r -I/opt/include -O2 -qmaxmem=-1 -I../../include -I../../../../src/openldap-2.4.48/include -I/opt/include -DLDAP_LIBRARY -c ../../../../src/openldap-2.4.48/libraries/libldap/tls2.c -o tls2.o "../../../../src/openldap-2.4.48/libraries/libldap/tls2.c", line 658.14: 1506-045 (S) Undeclared identifier LDAP_OPT_X_TLS_ECNAME. "../../../../src/openldap-2.4.48/libraries/libldap/tls2.c", line 658.14: 1506-051 (S) Case expression must be a valid integral constant. "../../../../src/openldap-2.4.48/libraries/libldap/tls2.c", line 781.14: 1506-045 (S) Undeclared identifier LDAP_OPT_X_TLS_ECNAME. "../../../../src/openldap-2.4.48/libraries/libldap/tls2.c", line 781.14: 1506-051 (S) Case expression must be a valid integral constant. make[2]: *** [Makefile:413: tls2.lo] Error 1 make[2]: Leaving directory '/data/prj/aixtools/static/openldap-2.4.48/libraries/libldap' make[1]: *** [Makefile:297: all-common] Error 1 make[1]: Leaving directory '/data/prj/aixtools/static/openldap-2.4.48/libraries' make: *** [Makefile:313: all-common] Error 1 Researching further... Michael

1 0

(ITS#9083) Broken link in the list of commercial support partners
by marketing＠daasi.de 18 Sep '19

18 Sep '19

Full_Name: Romy Hoffart Version: - OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.24.13.226) Hey everyone, I am with the marketing department of DAASI International, one of the commercial support partners for OpenLDAP listed on your website. Unfortunately I noticed that the link to our website doesn't work anymore. Could you replace the link here (https://www.openldap.org/support/) with a new link to our website (https://daasi.de/en/)? I was in touch with Quanah from Symas before, she recommended me to submit this issue here. Thank you so much for your time & help, Romy

1 0

Re: (ITS#9082) Issues while upgrading to 2.4.48
by quanah＠symas.com 18 Sep '19

18 Sep '19

--On Tuesday, September 17, 2019 6:47 PM +0000 krishradhe11(a)gmail.com wrote: > Full_Name: Radhe Krish > Version: 2.4.44 > OS: Centos 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (139.85.223.11) Hello, The ITS system is for reporting bugs, not usage questions. Please redirect your query to the openldap-technical(a)openldap.org email list for questions such as yours. I will note that this question has been asked and answered there already for other individuals, so if you look at the list archives, you'll find your answer. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> <https://www.openldap.org/lists/openldap-technical/> <https://www.openldap.org/lists/openldap-technical/201908/msg00157.html> This ITS will be closed. 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#9082) Issues while upgrading to 2.4.48
by krishradhe11＠gmail.com 17 Sep '19

17 Sep '19

Full_Name: Radhe Krish Version: 2.4.44 OS: Centos 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (139.85.223.11) Hello ! I 'm using Openldap version 2.4.44 running on my centos 7 machine. In process to upgrade to the recently released Openldap version 2.4.48, I'm facing some difficulties while choosing the concerned folder to save executable libraries. I followed the instructions as in official website but I'm not positive about how to upgrade from already installed Openldap 2.4.44 to 2.4.48. I tried to find RPMs supporting this but still no luck.Can you help me with clear instructions to proceed upgrade from 2.4.44 to 2.4.48 or help me with the corresponding RPM, that will be really helpful.

1 0

RE: (ITS#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 17 Sep '19

17 Sep '19

--_000_AM0PR0202MB3553BA671B52D50E489F7ACBBA8F0AM0PR0202MB3553_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGVsbG8gT25kxZllaiAsDQp0aGFua3MgYSBsb3QgZm9yIHdhcm5pbmcgbWUuDQpJIHdpbGwgdGVz dCB0aGUgbmV3IGNvZGUgd2l0aGluIGEgbW9udGggKEkgY2Fubm90IGRvIGl0IGF0IHRoaXMgdGlt ZSkuDQoNCklsIGtlZXAgeW91IGluZm9ybWVkLg0KDQpraW5kIHJlZ2FyZHMsDQoNCg0KSmVhbi1Q aGlsaXBwZSBBeWFuaWRlcw0KQ29uY2VwdGlvbiBldCBhcmNoaXRlY3R1cmUgc8OpY3VyaXTDqQ0K U2VydmljZSAmIE9wZXJhdGlvbiAvIEluZnJhc3RydWN0dXJlIE5ldHdvcmsgU2VjdXJpdHkgQmFj a2JvbmUNCnTDqWwgKzMzMTM0NDkwNjI4DQpQcm9zb2RpZS1DYXBnZW1pbmkNClBlb3BsZSBtYXR0 ZXIsIHJlc3VsdHMgY291bnQuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGUg OiBPbmTFmWVqIEt1em7DrWsgPG9uZHJhQG1pc3RvdGViZS5uZXQ+DQpFbnZvecOpIDogbWVyY3Jl ZGkgMTEgc2VwdGVtYnJlIDIwMTkgMTg6MDQNCsOAIDogQVlBTklERVMsIEpFQU4tUEhJTElQUEUg PGpwYXlhbmlkZXNAcHJvc29kaWUuY29tPg0KQ2MgOiBvcGVubGRhcC1pdHNAT3BlbkxEQVAub3Jn IDxvcGVubGRhcC1pdHNAT3BlbkxEQVAub3JnPg0KT2JqZXQgOiBSZTogKElUUyM5MDIzKSBjcmFz aCB1c2luZyBwcG9saWN5IGNoYWluaW5nIGZyb20gc2xhdmUgdG8gbWFzdGVyDQoNCkhpIEplYW4t UGhpbGlwcGUsDQpJIGhhdmUganVzdCBzZWVuIGFuZCBmaXhlZCBhIGNyYXNoIHRoYXQgbWlnaHQg YmUgc2ltaWxhciB0byB5b3Vycw0KKElUUyM5MDc2KSwgY291bGQgeW91IHRyeSBhbmQgc2VlIGlm IHRoZSBjcmFzaCBnb2VzIGF3YXkgaWYgeW91IGFwcGx5DQpjb21taXQgYTE0ZmI3MzFhYzZlMzlj ZDAzNzUxMmNhNjNiY2IwMjFmMDE5NmU1Yj8NCg0KVGhhbmtzLA0KDQotLQ0KT25kxZllaiBLdXpu w61rDQpTZW5pb3IgU29mdHdhcmUgRW5naW5lZXINClN5bWFzIENvcnBvcmF0aW9uICAgICAgICAg ICAgICAgICAgICAgICBodHRwOi8vd3d3LnN5bWFzLmNvbQ0KUGFja2FnZWQsIGNlcnRpZmllZCwg YW5kIHN1cHBvcnRlZCBMREFQIHNvbHV0aW9ucyBwb3dlcmVkIGJ5IE9wZW5MREFQDQpUaGlzIG1l c3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25m aWRlbnRpYWwgYW5kIGlzIHRoZSBwcm9wZXJ0eSBvZiB0aGUgQ2FwZ2VtaW5pIEdyb3VwLiBJdCBp cyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdCBhdXRob3Jp emVkIHRvIHJlYWQsIHByaW50LCByZXRhaW4sIGNvcHksIGRpc3NlbWluYXRlLCBkaXN0cmlidXRl LCBvciB1c2UgdGhpcyBtZXNzYWdlIG9yIGFueSBwYXJ0IHRoZXJlb2YuIElmIHlvdSByZWNlaXZl IHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UuCg== --_000_AM0PR0202MB3553BA671B52D50E489F7ACBBA8F0AM0PR0202MB3553_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij4NCkhlbGxvIDxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTFwdCI+T25kxZllaiA8L3NwYW4+PC9mb250Piw8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCnRoYW5rcyBhIGxvdCBmb3Igd2Fy bmluZyBtZS48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwg SGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwg MCk7Ij4NCkkgd2lsbCB0ZXN0IHRoZSBuZXcgY29kZSB3aXRoaW4gYSBtb250aCAoSSBjYW5ub3Qg ZG8gaXQgYXQgdGhpcyB0aW1lKS48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxp YnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9y OiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsg Y29sb3I6IHJnYigwLCAwLCAwKTsiPg0KSWwga2VlcCB5b3UgaW5mb3JtZWQuPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCmtpbmQgcmVn YXJkcyw8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwg MCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iU2lnbmF0dXJlIj4NCjxkaXYgaWQ9ImRp dnRhZ2RlZmF1bHR3cmFwcGVyIiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyBjb2xv cjojMDAwMDAwOyBmb250LWZhbWlseTpDYWxpYnJpLEhlbHZldGljYSxzYW5zLXNlcmlmIj4NCjxk aXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtc2l6ZTox MnB0OyBjb2xvcjojMDAwMDAwOyBiYWNrZ3JvdW5kLWNvbG9yOiNGRkZGRkY7IGZvbnQtZmFtaWx5 OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPg0KPHAgc3R5bGU9Im1hcmdpbi10 b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PHNwYW4gbGFuZz0iZnIiPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46MCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJv bWFuLHNlcmlmIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPjxmb250IHNpemU9IjIiIGZh Y2U9IlZlcmRhbmEsc2Fucy1zZXJpZiIgY29sb3I9IiMwMDQ2OEMiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OXB0Ij48Yj5KZWFuLVBoaWxpcHBlIEF5YW5pZGVzPGJyPg0KPC9iPjwvc3Bhbj48L2Zv bnQ+PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7IGZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9y OmJsYWNrIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0OyBmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+Q29uY2VwdGlv biBldCBhcmNoaXRlY3R1cmUgc8OpY3VyaXTDqTwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjhwdDsgZm9udC1mYW1pbHk6QXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPlNlcnZp Y2UgJmFtcDsgT3BlcmF0aW9uIC8gSW5mcmFzdHJ1Y3R1cmU8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjhw dDsgZm9udC1mYW1pbHk6QXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPg0KIE5ldHdvcmsgU2Vj dXJpdHkgQmFja2JvbmU8L3NwYW4+PGJyPg0KPGEgY2xhc3M9Im8zNjVidXR0b24iPjxzcGFuIGNs YXNzPSJtcy1mb250LXMgbXMtZm9udC1jb2xvci10aGVtZVByaW1hcnkiIHRpdGxlPSImIzQzOzMz MTM0NDkwNjI4Ij50w6lsICYjNDM7MzMxMzQ0OTA2Mjg8L3NwYW4+PC9hPjxicj4NClByb3NvZGll LUNhcGdlbWluaTxicj4NCjwvc3Bhbj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMDA5OENDIj5Q ZW9wbGUgbWF0dGVyLCByZXN1bHRzIGNvdW50Ljwvc3Bhbj48L3N0cm9uZz48L2Rpdj4NCjxzdHJv bmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7IGNvbG9yOiMwMDk4Q0MiPjwvc3Bhbj48L3N0cm9uZz48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBpZD0iYXBwZW5kb25zZW5kIj48L2Rpdj4NCjxociBzdHlsZT0iZGlzcGxheTppbmxp bmUtYmxvY2s7d2lkdGg6OTglIiB0YWJpbmRleD0iLTEiPg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1z ZyIgZGlyPSJsdHIiPjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIHN0eWxlPSJmb250 LXNpemU6MTFwdCIgY29sb3I9IiMwMDAwMDAiPjxiPkRlIDo8L2I+IE9uZMWZZWogS3V6bsOtayAm bHQ7b25kcmFAbWlzdG90ZWJlLm5ldCZndDs8YnI+DQo8Yj5FbnZvecOpIDo8L2I+IG1lcmNyZWRp IDExIHNlcHRlbWJyZSAyMDE5IDE4OjA0PGJyPg0KPGI+w4AgOjwvYj4gQVlBTklERVMsIEpFQU4t UEhJTElQUEUgJmx0O2pwYXlhbmlkZXNAcHJvc29kaWUuY29tJmd0Ozxicj4NCjxiPkNjJm5ic3A7 OjwvYj4gb3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZyAmbHQ7b3BlbmxkYXAtaXRzQE9wZW5MREFQ Lm9yZyZndDs8YnI+DQo8Yj5PYmpldCA6PC9iPiBSZTogKElUUyM5MDIzKSBjcmFzaCB1c2luZyBw cG9saWN5IGNoYWluaW5nIGZyb20gc2xhdmUgdG8gbWFzdGVyPC9mb250Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iQm9keUZyYWdtZW50Ij48Zm9udCBzaXplPSIyIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+SGkg SmVhbi1QaGlsaXBwZSw8YnI+DQpJIGhhdmUganVzdCBzZWVuIGFuZCBmaXhlZCBhIGNyYXNoIHRo YXQgbWlnaHQgYmUgc2ltaWxhciB0byB5b3Vyczxicj4NCihJVFMjOTA3NiksIGNvdWxkIHlvdSB0 cnkgYW5kIHNlZSBpZiB0aGUgY3Jhc2ggZ29lcyBhd2F5IGlmIHlvdSBhcHBseTxicj4NCmNvbW1p dCBhMTRmYjczMWFjNmUzOWNkMDM3NTEyY2E2M2JjYjAyMWYwMTk2ZTViPzxicj4NCjxicj4NClRo YW5rcyw8YnI+DQo8YnI+DQotLSA8YnI+DQpPbmTFmWVqIEt1em7DrWs8YnI+DQpTZW5pb3IgU29m dHdhcmUgRW5naW5lZXI8YnI+DQpTeW1hcyBDb3Jwb3JhdGlvbiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 YSBocmVmPSJodHRwOi8vd3d3LnN5bWFzLmNvbSI+aHR0cDovL3d3dy5zeW1hcy5jb208L2E+PGJy Pg0KUGFja2FnZWQsIGNlcnRpZmllZCwgYW5kIHN1cHBvcnRlZCBMREFQIHNvbHV0aW9ucyBwb3dl cmVkIGJ5IE9wZW5MREFQPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogOXB4OyBsaW5lLWhlaWdodDogMTBweDsiPlRoaXMgbWVzc2FnZSBj b250YWlucyBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlh bCBhbmQgaXMgdGhlIHByb3BlcnR5IG9mIHRoZSBDYXBnZW1pbmkgR3JvdXAuIEl0IGlzIGludGVu ZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90IGF1dGhvcml6ZWQgdG8g cmVhZCwgcHJpbnQsIHJldGFpbiwgY29weSwgZGlzc2VtaW5hdGUsIGRpc3RyaWJ1dGUsIG9yIHVz ZSB0aGlzIG1lc3NhZ2Ugb3IgYW55IHBhcnQgdGhlcmVvZi4gSWYgeW91IHJlY2VpdmUgdGhpcyBt ZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZS48L3NwYW4+PC9ib2R5Pg0KPC9odG1s Pg0K --_000_AM0PR0202MB3553BA671B52D50E489F7ACBBA8F0AM0PR0202MB3553_--

1 0

(ITS#9081) Memory leak in ldap_initialize/ldap_unbind
by jengelh＠inai.de 16 Sep '19

16 Sep '19

Full_Name: Jan Engelhardt Version: 2.4.48 OS: openSUSE Tumbleweed; Linux 5.3.0-rc7 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a02:8108:96c0:15fc:2137:8684:9608:51f8) » cat x.c #define LDAP_DEPRECATED 1 #include <ldap.h> int main() { LDAP *ld; ldap_initialize(&ld, "ldapi:///"); ldap_unbind(ld); } » gcc x.c -Wall -lldap -ggdb3 » valgrind --leak-check=full ./a.out ==25779== HEAP SUMMARY: ==25779== in use at exit: 26,395 bytes in 85 blocks ==25779== total heap usage: 233 allocs, 148 frees, 177,134 bytes allocated ==25779== ==25779== 40 bytes in 1 blocks are definitely lost in loss record 11 of 24 ==25779== at 0x4838B65: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==25779== by 0x4A8310C: ber_memcalloc_x (memory.c:283) ==25779== by 0x4A84EC0: ber_sockbuf_alloc (sockbuf.c:60) ==25779== by 0x487396A: ldap_create (open.c:172) ==25779== by 0x4873C8D: ldap_initialize (open.c:241) ==25779== by 0x10915F: main (x.c:6) ==25779== ==25779== LEAK SUMMARY: ==25779== definitely lost: 40 bytes in 1 blocks ==25779== indirectly lost: 0 bytes in 0 blocks ==25779== possibly lost: 0 bytes in 0 blocks ==25779== still reachable: 26,355 bytes in 84 blocks ==25779== suppressed: 0 bytes in 0 blocks ==25779== Reachable blocks (those to which a pointer was found) are not shown. ==25779== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==25779== ==25779== For lists of detected and suppressed errors, rerun with: -s ==25779== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) unbind.c: 123 for ( lm = ld->ld_responses; lm != NULL; lm = next ) { 128 if ( ld->ld_abandoned != NULL ) { 132 LDAP_MUTEX_UNLOCK( &ld->ld_res_mutex ); 136 ber_int_sb_destroy( ld->ld_sb ); Should this probably be LBER_FREE rather than ber_int_sb_destroy?

1 0

ITS#9080 a further relevant ITS
by Norman.Gray＠glasgow.ac.uk 14 Sep '19

14 Sep '19

I should also note that ITS#4996 (2007, closed) appears to be the issue=20 which resulted in the support for `-H "<proto>:///DN"` being added to=20 the command-line clients. --=20 Norman Gray : https://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK

1 0

(ITS#9080) Feature request: support DNS SRV lookups in ldap.conf
by gray＠nxg.name 14 Sep '19

14 Sep '19

Full_Name: Norman Gray Version: 2.4.47 OS: FreeBSD 12.0 (but not OS-soecific) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:8b0:df5:af53:c1a5:cbb2:6a6a:3390) Feature request: support specification of DNS SRV records in ldap.conf, matching ldapsearch -H The `ldapsearch` tools supports specifying lookups of SRV records via a special case syntax in the argument to the `-H` option. A URI such as ldap:///dc=ldap,dc=example,dc=com (with the commas and equals signs suitably escaped) prompts ldapsearch to do a lookup of an SRV record for ldap.example.com. However the URI synatx in ldap.conf doesn't have a corresponding special case, so it's not possible to put such a spec in a ldap.conf file. The ldap.conf documentation doesn't claim any support for SRV records, so there isn't a bug here, but on a Principle of Least Astonishment it would be very useful if the same syntax that -H respects were respected by ldap.conf as well. Other LDAP clients have different ways of specifying this (eg, nslcd.conf supports a `DNS:<domain>` syntax; Linux automount's `autofs.conf` has a `ldap_uri` attribute which supports a very similar dc=xxx syntax), so an alternative ldap.conf syntax would be a good second best. As an auxiliary point, when `ldapsearch` sees `URI ldap:///dc%3D...` in the ldap.conf file, it silently ignores it, rather than producing an error. It doesn't even produce a warning when `ldapsearch` is invoked with `-d-1`. I had to use strace to reassure myself that the config file was actually being read. I feel that a library should make a _lot_ more noise about an attribute in a configuration file being seen but ignored (I can see that the `ldap://dc...` URI, which is of course syntactically OK, _might_ be inadvertently meaningful, and thus not necessarily a detectable error, but even in that case `-d-1` should produce _something_). A scan through ITS reports found the following: * ITS#5919 (2009, still open) discusses a similar request, and discusses a variety of issues with it. This is a useful cross-reference. * ITS#6462 (2010, open) and ITS#8610 (2017, open) both touch on SRV records, but aren't particularly relevant, since they're both about the handling of ldaps:// URIs specifying a SRV record. * ITS#7027 (2011, closed) and ITS#8196 (open) are concerned with the internal handling of SRV records, but not their configuration $ ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.47 (Jul 25 2019 01:30:14) $ root@120amd64-quarterly-job-16:/wrkdirs/usr/ports/net/openldap24-sasl-client/work/openldap-2.4.47/clients/tools (LDAP library: OpenLDAP 20447)

1 0

Re: (ITS#9079 documentation: slapo-unique syntax explanation unclear
by quanah＠symas.com 13 Sep '19

13 Sep '19

--On Friday, September 13, 2019 6:07 PM +0000 gray(a)nxg.name wrote: > Full_Name: Norman Gray > Version: 2.4.48 > OS: FreeBSD 12.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.209.45.140) Note: this is now ITS#9079. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9078) Indices MDB
by quanah＠symas.com 13 Sep '19

13 Sep '19

--On Friday, September 13, 2019 5:54 PM +0000 dpa-openldap(a)aegee.org wrote: Hello, The ITS system is for bug reports, not usage questions. Please redirect your questions to the openldap-technical(a)openldap.org mailing list. This ITS will be closed. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9077) slapo-unique spins its wheels on a non-trivial olcUniqueURI spec
by quanah＠symas.com 13 Sep '19

13 Sep '19

--On Friday, September 13, 2019 4:34 PM +0000 gray(a)nxg.name wrote: > Full_Name: Norman Gray > Version: 2.4.48 > OS: FreeBSD 12.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.209.45.140) Unrelated side note, ITS number fixed to be 9077. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9488) documentation: slapo-unique syntax explanation unclear
by gray＠nxg.name 13 Sep '19

13 Sep '19

Full_Name: Norman Gray Version: 2.4.48 OS: FreeBSD 12.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.209.45.140) Documentation bug The documentation for the `unique_uri` or `olcUniqueURI` attribute is very compact, with the result that it is not clear what counts as correct syntax, nor what are the semantics of the specification. I'm not suggesting that the text is necessarily _inaccurate_, but that it is too brief. That is, someone who already understand the syntax and semantics will probably not notice anything wrong with this paragraph; someone who doesn't already understand (eg, me) will struggle. slapo-unique(5) says that the syntax here is: unique_uri <[strict ][ignore ]URI[URI...]...> Configure the base, attributes, scope, and filter for uniqueness checking. Multiple URIs may be specified within a domain, allowing complex selections of objects. Multiple unique_uri statements or olcUniqueURI attributes will create independent domains, each with their own independent lists of URIs and ignore/strict settings. Keywords strict and ignore have to be enclosed in quotes (") together with the URI. The LDAP URI syntax is a subset of RFC-4516, and takes the form: ldap:///[base dn]?[attributes...]?scope[?filter] I understand from this text the following: * One can specify multiple URIs in the value of a olcUniqueURI attribute. I _guess_ these can be space-separated, even though that isn't shown in this syntax. * Each URI defines a set of object attributes * One can have multiple olcUniqueURI attributes, _each of which_ creates a 'domain' * This doesn't say what a 'domain' is, but I _guess_ that it means that all of the attributes which match the search are forced, by this overlay, to be unique, but that there are no mutual uniqueness requirements between separate olcUniqueURI/'domain' specifications * If multiple URIs are specified in a 'domain', or olcUniqueURI attribute, then (wild guess) the union of the attributes matched by each URI is unique; I doubt it means the intersection of the result sets (I guess that because that's the only thing that sounds sensible; the phrase 'complex selections of objects' doesn't clarify) * It's not clear where the quotes go, when combining with 'strict' or 'ignore' (I guess "strict ldap://..."). * Can 'strict' or 'ignore' be combined with the second or subsequent URIs? The syntax suggests not. I don't think the above understanding is correct, because when I specify a olcUniqueURI attribute with multiple URIs, I get an error (see ITS#9486 and thread <https://www.openldap.org/lists/openldap-technical/201909/msg00031.html>). At any rate, I have little confidence that I have interpreted the text correctly, and the above is the result of several careful readings and some guesswork. If the above, or something like it, is roughly correct, I could draft an alternative paragraph, if that would be useful. If the manpage included more than one example, that would be _extremely_ useful. I'll mention in passing that in servers/slapd/overlays/unique.c, the comment above `unique_new_domain` says instead * domain_specs look like * * [strict ][ignore ]uri[[ uri]...] * e.g. "ldap:///ou=foo,o=bar?uid?sub ldap:///ou=baz,o=bar?uid?sub" * "strict ldap:///ou=accounts,o=bar?uid,uidNumber?one" * etc

1 0

(ITS#9487) Indices MDB
by dpa-openldap＠aegee.org 13 Sep '19

13 Sep '19

Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;&#1074; Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.118.146.153) How can I write to a ticket here, after I submit it? https://www.openldap.org/software/man.cgi?query=slapd-mdb&apropos=0&sektion… (man slapd-mdb) is not clear about indices. Is olcDbIndex A eq olcDbIndex B eq the same as olcDbIndex A,B eq and is the latter the same as oldDbIndex B,A eq ? In the SQL word these are different things and while Postgresql is supposed to handle "index A,B" and "index B.A" as equivalent, it does not, so a query has to be tuned to make use of existing indices. The particular use-case is the LDAP backend of MIT Kerberos and the indices it needs for this query, as discussed at https://github.com/krb5/krb5/pull/974#issuecomment-531167854. The debug output of OpenLDAP is: Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SRCH base="cn=X.NET,cn=krbContainer" scope=2 deref=0 filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=krbtgt/X.NET(a)X.NET))" Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SRCH attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewable age krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbPrincipalAuthInd krbExtraData krbObjectReferences krbAllowedToDelegateTo krbPwdHistory Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf <= mdb_equality_candidates: (objectClass) not indexed Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SEARCH RESULT tag=101 err=0 nentries=1 text= Does it need one index on objectClass, one index on krbPrincipal, or one index on "first objectClass, then krbPrincipal"? If no mdb_candidate output can be triggered, does it mean, that creating an index is pointless? Moreover, it is not clear when changing the oldDbIndex on a database regenerates the index, and when running slapindex is necessary.

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 13 Sep '19

13 Sep '19

On Mon, Sep 09, 2019 at 04:01:59PM +0200, Ond??ej Kuzn??k wrote: > I mean the ber_str2bv(,,1,) in both new functions. Not sure which code > you think would overwrite parts of the buffer? ber_str2bv(,,0,) never > touches it, manually initialising the berval certainly wouldn't either. > And then you have fewer memory regions to scrub. > > Since you already know the length, you can also pass it in so ber_str2bv > can skip its strlen() check (and since anything can be in a {PLAINTEXT} > password, you're now embedded NUL safe). Ah, OK, I didn't realize that would be NUL safe. I made an updated patch with that change[1]. > I think I mentioned this before as something worth changing: rather > than call time(0L), you can use op->o_time which is stable and the > closest you can get to the time the operation was received. Yes, sorry I did see that before just forgot to do it. It's also included in the latest update[1]. > BTW, scinet.supercomputing.org's HTTPS cert is signed by Let's Encrypt > Authority X3 as an intermediate, but isn't sending it during the > handshake, so wget/curl aren't happy trusting it (I think browsers cache > it or already have a copy). Thank you, this has been corrected. [1] https://scinet.supercomputing.org/~gv/slapd-totp-v5.txt -- Greg Veldman

1 0

(ITS#9486) slapo-unique spins its wheels on a non-trivial olcUniqueURI spec
by gray＠nxg.name 13 Sep '19

13 Sep '19

Full_Name: Norman Gray Version: 2.4.48 OS: FreeBSD 12.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.209.45.140) A plausible-looking spec in olcUniqueURI causes slapadd to spin its wheels indefinitely. I want to specify something like: dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueURI: ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub If I do this, however, then slapadd spins its wheels when the `slapd.ldif` is loaded into an otherwise empty configuration (ie, this happens at configuration time, before any records/objects are loaded): $ rm -R /usr/local/etc/openldap/slapd.d/* $ su -m ldap -c "slapadd -d255 -n 0 -F /usr/local/etc/openldap/slapd.d -l /usr/local/etc/openldap/slapd.ldif" ... ... 5d77d377 >>> dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <<< dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config>, <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <= str2entry(olcOverlay=unique,olcDatabase={1}mdb,cn=config) -> 0x800d4eca8 5d77d377 oc_check_required entry (olcOverlay=unique,olcDatabase={1}mdb,cn=config), objectClass "olcUniqueConfig" 5d77d377 oc_check_allowed type "objectClass" 5d77d377 oc_check_allowed type "olcOverlay" 5d77d377 oc_check_allowed type "olcUniqueURI" 5d77d377 oc_check_allowed type "structuralObjectClass" 5d77d377 >>> dnNormalize: <olcOverlay={1}unique> 5d77d377 <<< dnNormalize: <olcOverlay={1}unique> 5d77d377 ==> unique_db_init 5d77d377 ==> unique_new_domain <ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub> 5d77d377 >>> dnPrettyNormal: <ou=dept-A,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-A,o=example>, <ou=dept-A,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> ... ^C and so on and on and on, apparently indefinitely. The idea is that the uidnumber attribute should be unique across the two OUs, ou=dept-A and ou=dept-B. Whether or not this is a valid spec is another issue; even if it's invalid, it shouldn't cause this behaviour; if the spec is invalid, it should produce a terminal error. Looking at the code in servers/slapd/overlays/unique.c, nothing leaps out as an obvious error (ie, I'm not claiming I have a fix for this). There was a brief thread about this on openldap-technical: <https://www.openldap.org/lists/openldap-technical/201909/msg00031.html> Configuration: # /usr/local/libexec/slapd -VVV @(#) $OpenLDAP: slapd 2.4.48 (Sep 10 2019 13:30:19) $ root@hermite.physics.gla.ac.uk:/var/ports/usr/ports/net/openldap24-server/work/openldap-2.4.48/servers/slapd Included static overlays: constraint syncprov unique Included static backends: config ldif relay # freebsd-version 12.0-RELEASE-p9 This is the most recent currently-packaged version of OpenLDAP on FreeBSD.

1 0

Re: (ITS#9023) crash using ppolicy chaining from slave to master
by ondra＠mistotebe.net 11 Sep '19

11 Sep '19

Hi Jean-Philippe, I have just seen and fixed a crash that might be similar to yours (ITS#9076), could you try and see if the crash goes away if you apply commit a14fb731ac6e39cd037512ca63bcb021f0196e5b? Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#9076) back-ldap tries to free the wrong controls
by ondra＠openldap.org 10 Sep '19

10 Sep '19

Full_Name: Ondrej Kuznik Version: re24/master OS: URL: Submission from: (NULL) (82.132.242.212) ldap_back_extended_one needs to play with op->o_ctrls since it doesn't just pass ctrls over like the other sites in back-ldap, but it never sets oldctrls as is should. If a control is ever added to the list, it will restore op->o_ctrls to the wrong value and crash. This happens e.g. in certain chaining scenarios with mode=legacy.

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by ondra＠mistotebe.net 09 Sep '19

09 Sep '19

On Thu, Sep 05, 2019 at 10:59:46AM -0400, Greg Veldman wrote: > On Thu, Sep 05, 2019 at 11:52:45AM +0200, Ond??ej Kuzn??k wrote: >> - could you split it in two patches, one to check the previous time step >> (+doc) and one to support the new schemes (+doc)? > > Working on it, will have updated patches up shortly... Thanks for the updated patches. >> - I don't think you need to allocate a copy of the passwd just come in, >> you can just frame it into separate bervals reusing the provided >> buffer so long as you keep in mind they are not NUL-terminated >> properly. > > Are you referring to the chk_totp_and_pw() function? If so, > since the expected format is <password><totp> with no seperator, > if I terminated the password part that would overwrite the first > char of totp, yes? That's the reason I make a copy and allocate > an extra byte for the NUL. I mean the ber_str2bv(,,1,) in both new functions. Not sure which code you think would overwrite parts of the buffer? ber_str2bv(,,0,) never touches it, manually initialising the berval certainly wouldn't either. And then you have fewer memory regions to scrub. Since you already know the length, you can also pass it in so ber_str2bv can skip its strlen() check (and since anything can be in a {PLAINTEXT} password, you're now embedded NUL safe). >> Just a style note, if there's an else coming, could you make sure both >> the if and the else blocks are in {}? > > Implemented, it will be included in the updated patches. I think I mentioned this before as something worth changing: rather than call time(0L), you can use op->o_time which is stable and the closest you can get to the time the operation was received. BTW, scinet.supercomputing.org's HTTPS cert is signed by Let's Encrypt Authority X3 as an intermediate, but isn't sending it during the handshake, so wget/curl aren't happy trusting it (I think browsers cache it or already have a copy). Thanks, -- 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#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 06 Sep '19

06 Sep '19

On Thu, Sep 05, 2019 at 10:59:46AM -0400, Greg Veldman wrote: > On Thu, Sep 05, 2019 at 11:52:45AM +0200, Ond??ej Kuzn??k wrote: > > - could you split it in two patches, one to check the previous time step > > (+doc) and one to support the new schemes (+doc)? > > Working on it, will have updated patches up shortly... Sorry that took a bit longer than I thought, got tied up with day job stuff yesterday afternoon. New patches are available that break out the two changes: https://scinet.supercomputing.org/~gv/slapd-totp-v4.txt https://scinet.supercomputing.org/~gv/slapd-totp-accept-previous-time-v1.txt -- Greg Veldman

1 0

Re: (ITS#9069) Stop setting custom GnuTLS mutex functions
by ryan＠nardis.ca 06 Sep '19

06 Sep '19

I know the locking gets exercised (both libldap and GnuTLS sides) during connection and TLS handshake, so I tested this by doing a bind/search/unbind loop on a bunch of parallel threads. I built master with this patch in all of the following environments: Debian 8 (jessie), GnuTLS 3.3.30 Debian 9 (stretch), GnuTLS 3.5.8 Debian 10 (buster), GnuTLS 3.6.7 Debian unstable (sid), GnuTLS 3.6.9 FreeBSD 12.0, GnuTLS 3.6.8 Solaris 11.4, GnuTLS 3.5.16, --with-threads=lwp Solaris 11.4, GnuTLS 3.5.16, --with-threads=posix Windows 10 (MinGW), GnuTLS 3.6.8, --with-threads=nt Windows 10 (MinGW), GnuTLS 3.6.8, --with-threads=posix and ran my test program successfully on all of them. On each of these I also stepped into the debugger and confirmed that the expected calls happened (gnutls_system_mutex_lock calling resp. pthread_mutex_lock or EnterCriticalSection, ldap_pvt_thread_mutex_lock calling the expected API, etc). Any further comments, or suggestions for additional tests I should run?

1 0

ITS#9075 published: SECURITY: Not able to view directory structure in 389 management Console
by openldap-its＠OpenLDAP.org 06 Sep '19

06 Sep '19

Private ITS#9075 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=9075

1 0

ITS#9074 published: SECURITY: Not able to view directory structure in 389 management Console
by openldap-its＠OpenLDAP.org 06 Sep '19

06 Sep '19

Private ITS#9074 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=9074

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 05 Sep '19

05 Sep '19

On Thu, Sep 05, 2019 at 11:52:45AM +0200, Ond??ej Kuzn??k wrote: > - could you split it in two patches, one to check the previous time step > (+doc) and one to support the new schemes (+doc)? Working on it, will have updated patches up shortly... > - I don't think you need to allocate a copy of the passwd just come in, > you can just frame it into separate bervals reusing the provided > buffer so long as you keep in mind they are not NUL-terminated > properly. Are you referring to the chk_totp_and_pw() function? If so, since the expected format is <password><totp> with no seperator, if I terminated the password part that would overwrite the first char of totp, yes? That's the reason I make a copy and allocate an extra byte for the NUL. > Just a style note, if there's an else coming, could you make sure both > the if and the else blocks are in {}? Implemented, it will be included in the updated patches. -- Greg Veldman

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by ondra＠mistotebe.net 05 Sep '19

05 Sep '19

On Wed, Jul 31, 2019 at 08:14:55PM +0000, gv(a)members.scinet.supercomputing.org wrote: > v3 of the patch is available, which includes hashing functions > and documents the expected input format when using those functions. > I don't have the updated module on any of my servers yet, but > running slappasswd from my build directory does seem to yield > the same results as the non-password versions: > > $ ../../../../servers/slapd/slappasswd -T passwd -o module-load=`pwd`/.libs/pw-totp.so -h "{TOTP1}" > New password: > Re-enter new password: > {TOTP1}GAYA==== > > $ ../../../../servers/slapd/slappasswd -T passwd -o module-load=`pwd`/.libs/pw-totp.so -h "{TOTP1ANDPW}" > New password: > Re-enter new password: > {TOTP1ANDPW}GAYA====|{SSHA}Qo6WiIWWsWohlwZSo9oQkImKvSNArGio > > This is using an OTP seed of 00 and a password of foo > > https://scinet.supercomputing.org/~gv/slapd-totp-v3.txt Hi Greg, looking at the code, I think I'd be ok with this functionality and nothing major comes up for me. I would like to see a few changes though: - could you split it in two patches, one to check the previous time step (+doc) and one to support the new schemes (+doc)? - I don't think you need to allocate a copy of the passwd just come in, you can just frame it into separate bervals reusing the provided buffer so long as you keep in mind they are not NUL-terminated properly. Just a style note, if there's an else coming, could you make sure both the if and the else blocks are in {}? Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

答复: (ITS#9072) openLdap client problem
by feng.wang＠iquantex.com 02 Sep '19

02 Sep '19

--_6DA7EF0F-7766-481F-9373-22F0846C9405_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Thank you for your reply! =C2=A0=C2=A0=C2=A0=C2=A0 This problem has been solved, not the openldap pro= blem, but the problem with the use of the sssd service. Of course, I will c= onsider your suggestion to upgrade to version 2.4.48. =E5=8F=91=E9=80=81=E8=87=AA Windows 10 =E7=89=88=E9=82=AE=E4=BB=B6=E5=BA=94= =E7=94=A8 =E5=8F=91=E4=BB=B6=E4=BA=BA: Quanah Gibson-Mount =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B48=E6=9C=8830=E6=97=A5 22= :07 =E6=94=B6=E4=BB=B6=E4=BA=BA: feng.wang(a)iquantex.com; openldap-its(a)OpenLDAP.= org =E4=B8=BB=E9=A2=98: Re: (ITS#9072) openLdap client problem --On Friday, August 30, 2019 7:14 AM +0000 feng.wang(a)iquantex.com wrote: > Thank you very much for getting support! > ???? In the production of openldap is the HA environment, other uses are > normal, only in the modification of the user to multiple groups (some > client new user information is updated, and some other host clients are > not updated). Please update to a current release of OpenLDAP, i.e, at least version=20 2.4.48 as numerous replication fixes have been made to the product since=20 that time. You were already told to upgrade in ITS#9053 as well. Please=20 stop filing ITSes until such a time as you have upgraded to a current=20 release. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --_6DA7EF0F-7766-481F-9373-22F0846C9405_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht= tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name= =3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style></style></head><body lang=3DZH-CN link=3Dblue vlink=3D"#954F72"><div cla= ss=3DWordSection1>Thank you for you= r reply!  &nbs= p;  This problem has been solved, not the openldap problem, but the pr= oblem with the use of the sssd service. Of course, I will consider your sug= gestion to upgrade to version 2.4.48.<o:p></o:p><o:p> </o:p>=E5=8F=91=E9=80=81=E8=87= =AA Windows 10 =E7=89=88<a hre= f=3D"https://go.microsoft.com/fwlink/?LinkId=3D550986"><= span lang=3DEN-US>=E9=82=AE=E4=BB=B6</a>=E5=BA=94=E7= =94=A8<o:p> </o:p><div style=3D'mso-element:= para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0c= m 0cm 0cm'>=E5=8F= =91=E4=BB=B6=E4=BA=BA: <a = href=3D"mailto:quanah@symas.com">Quanah Gibson-Mount</a> =E5= =8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B48=E6=9C=8830=E6=97=A5 22:07 =E6=94=B6= =E4=BB=B6=E4=BA=BA: <a hre= f=3D"mailto:feng.wang@iquantex.com">feng.wang(a)iquantex.com</a>; <a href=3D"= mailto:openldap-its@OpenLDAP.org">openldap-its(a)OpenLDAP.org</a> <= b>=E4=B8=BB=E9=A2=98: Re: = (ITS#9072) openLdap client problem</div><sp= an lang=3DEN-US style=3D'font-size:12.0pt;font-family:SimSun'><o:p> </= o:p><o:p> </o:p></s= pan><o:p> </o:p></p= >--On Friday, August 30, 2019 7:14 = AM +0000 feng.wang(a)iquantex.com wrote:<span= lang=3DEN-US><o:p> </o:p>> Thank you very much for getting support!> ???? In the production of openldap is = the HA environment, other uses are> normal, only in the modification of the user to multiple gro= ups (some> client new= user information is updated, and some other host clients are> not updated).<o:p> </o:p>Please update to a current release of OpenLDAP, i.= e, at least version 2.4.= 48 as numerous replication fixes have been made to the product since </span= >that time.=C2=A0 You were alre= ady told to upgrade in ITS#9053 as well.=C2=A0 Please stop filing ITSes until such a time as you = have upgraded to a current release.<o:p> </= o:p>Regards,<= p class=3DMsoNormal>Quanah<o:p> </o:p><span= lang=3DEN-US><o:p> </o:p>--<o:p> </= o:p>Quanah Gibson-Mount<= /span>Product Architect<= /p>Symas CorporationPackaged, certified, and supported LDAP= solutions powered by OpenLDAP:<http://www.symas.com><o:p> </o:p></div></body></html>= --_6DA7EF0F-7766-481F-9373-22F0846C9405_--

1 0

Re: (ITS#8383) msys build error "portable.h:1116:19: error: two or more data types in declaration specifiers"
by ryan＠nardis.ca 01 Sep '19

01 Sep '19

I've run into this myself while trying to test ITS#9069 on Windows. In my MinGW environment, <sys/socket.h> does not define socklen_t, so portable.h:1116 does '#define socklen_t int'. However, <ac/socket.h> includes <ws2tcpip.h> which does typedef socklen_t. base64.c includes "portable.h" first and then <ac/socket.h> later. This second include triggers the error as the original typedef essentially becomes "typedef int int". I think we can fix it by searching the Windows header as well, avoiding the #define appearing in "portable.h". https://github.com/openldap/openldap/compare/openldap:master...rtandy:its83…

1 0

Re: (ITS#9073) md_cmp() called with zero size key
by juerg.bircher＠gmail.com 31 Aug '19

31 Aug '19

After having investigated more time on this issue and having changed = some parts of my code which could cause data corruption everything seems = to work fine. So most likely this issue can be closed.=

1 0

(ITS#9073) md_cmp() called with zero size key
by juerg.bircher＠gmail.com 31 Aug '19

31 Aug '19

Full_Name: Juerg Bircher Version: LMDB master OS: macOS / linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.75.150.99) I had the situation that my custom compare function was called with a MDB_val with zero size. I assume this should never happen as a key with zero length should not be valid? Unfortunately I do not have a simple case to reproduce it as it happens in large transaction with a lot of mdb_cursor_put() interleaved with mdb_cursor_get() calls. However it is reproducible. In mdb_cursor_set() at line mdb.c:6943 nodekey.mv_size is zero. rc = mc->mc_dbx->md_cmp(key, &nodekey); So the custom compare function is called with a value of zero length. A possible fix could be to surrond the code from line 6943 to 7007 with a check if (nodekey.mv_size > 0) { rc = mc->mc_dbx->md_cmp(key, &nodekey); if (rc == 0) { line 6943 to 7007 } I thank you in advance to inform me: a. if this fix is correct b. my assumption is wrong c. it needs another fix somewhere else

1 0

Re: (ITS#9072) openLdap client problem
by quanah＠symas.com 30 Aug '19

30 Aug '19

--On Friday, August 30, 2019 7:14 AM +0000 feng.wang(a)iquantex.com wrote: > Thank you very much for getting support! > ???? In the production of openldap is the HA environment, other uses are > normal, only in the modification of the user to multiple groups (some > client new user information is updated, and some other host clients are > not updated). Please update to a current release of OpenLDAP, i.e, at least version 2.4.48 as numerous replication fixes have been made to the product since that time. You were already told to upgrade in ITS#9053 as well. Please stop filing ITSes until such a time as you have upgraded to a current release. 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#87) openLdap client problem
by feng.wang＠iquantex.com 30 Aug '19

30 Aug '19

Full_Name: wangfeng Version: 2.4.44 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (1.180.156.107) Thank you very much for getting support! In the production of openldap is the HA environment, other uses are normal, only in the modification of the user to multiple groups (some client new user information is updated, and some other host clients are not updated).

1 0

Re: (ITS#9070) Failing to include openssl1.1.1c with openLDAP
by quanah＠symas.com 29 Aug '19

29 Aug '19

--On Thursday, August 29, 2019 3:13 PM +0000 vishal.bafna307(a)gmail.com wrote: > I am trying to build openLDAP using openssl1.1.1c. > It is failing to locate the SSL/TLS package. > I have given the openssl lib and include paths in LDFLAGS and CPPFLAGS > respectively in the Makefile of LDAP. The Make file also has > --with-tls=openssl \ mentioned as config option The ITS system is for bug reports, not help requests on how to build the software. If you need help with building the software, please use the openldap-technical(a)openldap.org email list. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> This ITS will be closed. 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#9071) Invalid olcDbStartTLS values generated on back-ldap conversion
by quanah＠openldap.org 29 Aug '19

29 Aug '19

Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) When converting this basic slapd.conf for back-ldap: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/ppolicy.schema include /usr/local/etc/openldap/schema/misc.schema loglevel 256 pidfile /var/run/slapd.pid argsfile /var/run/slapd.args modulepath /usr/local/libexec/openldap moduleload rwm moduleload back_ldap database ldap readonly yes protocol-version 3 rebind-as-user yes uri "ldaps://universe.example.com" suffix "dc=universe,dc=example,dc=com" overlay rwm rwm-map attribute uid sAMAccountName rwm-map attribute mail proxyAddresses chase-referrals yes idassert-bind bindmethod=simple binddn="cn=ldap_phone,ou=LDAP Access,dc=example,dc=com" credentials='Password1234' tls_cacert=/usr/local/etc/openldap/example_com_Universe_Root_CA.cer The resulting back-ldap configuration has an invalid olcDbStartTLS attribute: olcDbStartTLS: none starttls=no Per the man page, "none" is not valid at all, and also per the man page, since the URI is using ldaps, the value should be: olcDbStartTLS: ldaps Config is based off of a real life configuration from an end user, where things worked with slapd.conf but were broken post-conversion to cn=config. Fixing the olcDbStartTLS value to be valid resolved the issue.

1 0

(ITS#9070) Failing to include openssl1.1.1c with openLDAP
by vishal.bafna307＠gmail.com 29 Aug '19

29 Aug '19

Full_Name: Vishal Bafna Version: 2.4.42 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.204.193.36) I am trying to build openLDAP using openssl1.1.1c. It is failing to locate the SSL/TLS package. I have given the openssl lib and include paths in LDFLAGS and CPPFLAGS respectively in the Makefile of LDAP. The Make file also has --with-tls=openssl \ mentioned as config option snapshot of config option in the ldap Makefile CONFIG_OPTS= --host=$(TARGET) --prefix=${LINUX_ROOT} --exec_prefix=${LINUX_ROOT} --disable-static --enable-shared --with-yielding_select=no --disable-slapd --enable-syslog --disable-bdb --disable-hdb --enable-debug --with-tls=openssl --target=$(TARGET) LDFLAGS="-L${LINUX_ROOT}/lib -L$(LINUX_ROOT)/ssl/lib" CPPFLAGS="-I${LINUX_ROOT}/include -I$(LINUX_ROOT)/ssl/include" \ checking for SSL_library_init in -lssl... no checking for ssl3_accept in -lssl... no configure: error: Could not locate TLS/SSL package Makefile:27: recipe for target 'configure_arm-none-linux-gnueabi-2.4.42' failed Could someone please help with the issue

1 0

Re: (ITS#9069) Stop setting custom GnuTLS mutex functions
by hyc＠symas.com 28 Aug '19

28 Aug '19

Ryan Tandy wrote: > On Wed, Aug 28, 2019 at 01:34:31PM +0100, Howard Chu wrote: >> This is not a safe assumption on Windows, unfortunately. While libldap uses native >> Windows mutexes on Windows, a lot of code built using gcc/g++ uses a posixthreads >> emulation library for thread and mutex support, and the user-visible structures are >> not compatible with native mutexes. (I've found this to be a significant problem >> for g++ std::mutex, std::thread, etc.) > > Thanks for mentioning that. GnuTLS also uses native Windows threads when building for Windows (including mingw-ish environments), so it should still be OK; but > I'd better go and figure out a smoke test on Windows too. > > How does this work on the OpenSSL side? For 1.1.0+ it sounds like the same situation, with OpenSSL using the Windows native API as well. > > Does "incompatible" just mean that a single mutex object can't be shared between the two APIs? (I don't think that would be an issue for our case.) Or is it > something stronger like a pthreads mutex not being able to synchronize native threads, or outright not being able to use both interfaces in a single process? > Passing a native structure to the posixthreads interface (and vice versa) will crash the program (or worse - silently corrupt memory without crashing the program....) -- -- 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#9069) Stop setting custom GnuTLS mutex functions
by ryan＠nardis.ca 28 Aug '19

28 Aug '19

On Wed, Aug 28, 2019 at 01:34:31PM +0100, Howard Chu wrote: >This is not a safe assumption on Windows, unfortunately. While libldap uses native >Windows mutexes on Windows, a lot of code built using gcc/g++ uses a posixthreads >emulation library for thread and mutex support, and the user-visible structures are >not compatible with native mutexes. (I've found this to be a significant problem >for g++ std::mutex, std::thread, etc.) Thanks for mentioning that. GnuTLS also uses native Windows threads when building for Windows (including mingw-ish environments), so it should still be OK; but I'd better go and figure out a smoke test on Windows too. How does this work on the OpenSSL side? For 1.1.0+ it sounds like the same situation, with OpenSSL using the Windows native API as well. Does "incompatible" just mean that a single mutex object can't be shared between the two APIs? (I don't think that would be an issue for our case.) Or is it something stronger like a pthreads mutex not being able to synchronize native threads, or outright not being able to use both interfaces in a single process?

1 0

Re: (ITS#9069) Stop setting custom GnuTLS mutex functions
by hyc＠symas.com 28 Aug '19

28 Aug '19

ryan(a)openldap.org wrote: > Full_Name: Ryan Tandy > Version: master > OS: Debian > URL: https://github.com/rtandy/openldap/compare/openldap:master...rtandy:remove-… > Submission from: (NULL) (70.66.128.207) > Submitted by: ryan > > > The GnuTLS documentation > <https://gnutls.org/manual/html_node/Core-TLS-API.html#gnutls_005fglobal_005…> > states: > >> Do not call this function from a library, or preferably from any application > unless really needed to. > Additionally, the custom mutex functions are never reset, so if libldap is > unloaded (for example via dlclose()) after calling this, its code may be > unmapped and the application could crash when GnuTLS calls the mutex functions. > > On typical systems, GnuTLS system mutexes are probably the same as what libldap > uses anyway. This is not a safe assumption on Windows, unfortunately. While libldap uses native Windows mutexes on Windows, a lot of code built using gcc/g++ uses a posixthreads emulation library for thread and mutex support, and the user-visible structures are not compatible with native mutexes. (I've found this to be a significant problem for g++ std::mutex, std::thread, etc.) > > IPR: > > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch were > developed by Ryan Tandy <ryan(a)nardis.ca>. I have not assigned rights and/or > interest in this work to any party. > > I, Ryan Tandy, 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. > > -- -- 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#9069) Stop setting custom GnuTLS mutex functions
by ondra＠mistotebe.net 28 Aug '19

28 Aug '19

On Wed, Aug 28, 2019 at 01:04:25AM +0000, ryan(a)openldap.org wrote: > The GnuTLS documentation states: >> Do not call this function from a library, or preferably from any application >> unless really needed to. > > I disobeyed that guidance in commit 829027945, because I wasn't sure that > GnuTLS's own threading support would cover all the platforms libldap does. This > choice caused some bugs, e.g. <https://bugs.debian.org/803197> and > <https://www.openldap.org/its/?findid=8797>. > > I don't know how to find out for sure whether anyone builds libldap with GnuTLS > on a system where it lacks native mutexes. I think at this point I would rather > fix the known broken cases, over the risk of potentially breaking a theoretical > setup I'm not sure actually exists. > > Therefore: I now propose applying this change for 2.5. A similar change (making tlso_thr_init a no-op) has been introduced in ITS#8533 when compiling with OpenSSL 1.1.0+, so I gather it should be fine for GnuTLS as well. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#9069) Stop setting custom GnuTLS mutex functions
by ryan＠openldap.org 28 Aug '19

28 Aug '19

Full_Name: Ryan Tandy Version: master OS: Debian URL: https://github.com/rtandy/openldap/compare/openldap:master...rtandy:remove-… Submission from: (NULL) (70.66.128.207) Submitted by: ryan The GnuTLS documentation <https://gnutls.org/manual/html_node/Core-TLS-API.html#gnutls_005fglobal_005…> states: > Do not call this function from a library, or preferably from any application unless really needed to. I disobeyed that guidance in commit 829027945, because I wasn't sure that GnuTLS's own threading support would cover all the platforms libldap does. This choice caused some bugs, e.g. <https://bugs.debian.org/803197> and <https://www.openldap.org/its/?findid=8797>. I don't know how to find out for sure whether anyone builds libldap with GnuTLS on a system where it lacks native mutexes. I think at this point I would rather fix the known broken cases, over the risk of potentially breaking a theoretical setup I'm not sure actually exists. Therefore: I now propose applying this change for 2.5. I made this change as a distro patch in Debian 10 (buster), and no Debian or Ubuntu users have reported any regressions so far. I also did some local testing with slapd and slapd-mtread on the GnuTLS versions shipped in the last few releases of Debian. I have not tested any non-Linux platforms yet. For completeness, I should probably try this on at least FreeBSD and Solaris. I kind of assume GnuTLS system mutexes are going to work anywhere LMDB already does. Rationale for the change, from the commit message: Since GnuTLS moved to implicit initialization on library load, calling this function deinitializes GnuTLS and then re-initializes it. When GnuTLS uses /dev/urandom as an entropy source (getrandom() not available, or older versions of GnuTLS), and the application closed all file descriptors at startup, this could result in GnuTLS opening /dev/urandom over one of the application's file descriptors when re-initialized. Additionally, the custom mutex functions are never reset, so if libldap is unloaded (for example via dlclose()) after calling this, its code may be unmapped and the application could crash when GnuTLS calls the mutex functions. On typical systems, GnuTLS system mutexes are probably the same as what libldap uses anyway. IPR: The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Ryan Tandy <ryan(a)nardis.ca>. I have not assigned rights and/or interest in this work to any party. I, Ryan Tandy, 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

Re: (ITS#8753) Public key pinning support in libldap
by ryan＠nardis.ca 27 Aug '19

27 Aug '19

The gnutls_digest_get_id function was added in GnuTLS 3.2.2: https://gitlab.com/gnutls/gnutls/blob/gnutls_3_2_2/NEWS That was released in 2013, so I think it's OK to depend on it by now. Please consider applying this patch to update the configure.in check: https://github.com/openldap/openldap/compare/master...rtandy:its8753-gnutls… Currently master fails to compile with older GnuTLS (e.g. on Debian 7/wheezy) after configure succeeded.

1 0

(ITS#9068) mdb_load corrupts escaped backslash
by hyc＠openldap.org 26 Aug '19

26 Aug '19

Full_Name: Howard Chu Version: 0.9.24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.233.39.186) Submitted by: hyc When reloading a printable dump (from mdb_dump -p), actual backslashes in the input (represented as '\\') will be corrupted. This has been broken since mdb_load was written in 2004.

1 0

Re: (ITS#9067) preferredDeliveryMethod syntax evaluation incorrect
by hyc＠symas.com 26 Aug '19

26 Aug '19

bremer(a)univention.de wrote: > Full_Name: Julia Bremer > Version: 2.4.45 > OS: debian / UCS 4.4 > URL: http://updates.software-univention.de/download/temp/openldap/fix-syntax-eva… > Submission from: (NULL) (82.198.197.8) > > > Trying to set the value of the attribute preferredDeliveryMethod to a sequence > of items, separated by " $ ", e.g "telephone $ videotex" fails with > > ldap_modify: Invalid syntax (21) > additional info: preferredDeliveryMethod: value #0 invalid per syntax > > even though the syntax is correct according to the RFC4517 > (Syntax 1.3.6.1.4.1.1466.115.121.1.14). > https://tools.ietf.org/html/rfc4517#section-3.3.5 > > This is due to an error in the method deliveryMethodValidate in > servers/slapd/schema_init.c which causes the function to check the string > backwards after a space character occurs. > The attached patch fixes this, so that the syntax is validated correctly. Thanks for the report, committed to master. Looks like this code has never been used since Kurt wrote it in 2004. I've tested it locally now but would ask whether you have time to also add a check into the test suite. Thanks. > > > Univention 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. > > -- -- 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#9067) preferredDeliveryMethod syntax evaluation incorrect
by bremer＠univention.de 26 Aug '19

26 Aug '19

Full_Name: Julia Bremer Version: 2.4.45 OS: debian / UCS 4.4 URL: http://updates.software-univention.de/download/temp/openldap/fix-syntax-eva… Submission from: (NULL) (82.198.197.8) Trying to set the value of the attribute preferredDeliveryMethod to a sequence of items, separated by " $ ", e.g "telephone $ videotex" fails with ldap_modify: Invalid syntax (21) additional info: preferredDeliveryMethod: value #0 invalid per syntax even though the syntax is correct according to the RFC4517 (Syntax 1.3.6.1.4.1.1466.115.121.1.14). https://tools.ietf.org/html/rfc4517#section-3.3.5 This is due to an error in the method deliveryMethodValidate in servers/slapd/schema_init.c which causes the function to check the string backwards after a space character occurs. The attached patch fixes this, so that the syntax is validated correctly. Univention 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

Re: (ITS#9066) Missing custom attrs after restart slapd
by quanah＠symas.com 22 Aug '19

22 Aug '19

--On Thursday, August 22, 2019 12:08 PM +0000 juanma171(a)yahoo.es wrote: > Full_Name: JuanMa > Version: 2.4.45 > OS: Ubuntu 18.04.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.176.151.51) > > > Afeter creating custom attrs, I can see in ldap browser, but after > restart sldap daemon, custom attrs are missing (sorry, bad english) > OLC mode and mdb database Hello, That is not the correct way to modify the schema or add new attributes. Please use the openldap-technical(a)openldap.org list for help. This ITS will be closed. 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#1505) Missing custom attrs after restart slapd
by juanma171＠yahoo.es 22 Aug '19

22 Aug '19

Full_Name: JuanMa Version: 2.4.45 OS: Ubuntu 18.04.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.176.151.51) Afeter creating custom attrs, I can see in ldap browser, but after restart sldap daemon, custom attrs are missing (sorry, bad english) OLC mode and mdb database LDIF for attr: dn: cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 1.3.6.1.4.1.8876.2.1.1 NAME 'mOL-APIKey' DESC 'API Key' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64512} SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.8876.2.1.2 NAME 'mOL-APISecretKey' DESC 'API Secret Key' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64512} SINGLE-VALUE ) after restart slapd: ldapsearch -x -LLL -b cn=Subschema -s base '(objectClass=subschema)' attributeTypes | grep mOL-APIKey doesn't show anything

1 0

(ITS#9065) slapo-ppolicy(5) man page refers to wrong attribute
by quanah＠openldap.org 19 Aug '19

19 Aug '19

Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) The slapo-ppolicy(5) man page has this statement in the description of pwdGraceUseTime: If too many grace logins have been used (please refer to the pwdGraceLoginLimit password policy attribute), However, there is no such attribute as "pwdGraceLoginLimit". It is instead pwdGraceAuthnLimit

1 0

Re: (ITS#9064) client tools not recognizing BINDDN from ldap.conf
by quanah＠symas.com 18 Aug '19

18 Aug '19

--On Sunday, August 18, 2019 12:19 AM +0000 fabrice.ducos(a)gmail.com wrote: > In my ldap.conf The ldap.conf(5) man page clearly states that the BINDDN variable is a USER ONLY option. That means it will only be honored if it appears in the ~user/.ldaprc file. This ITS will be closed. 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#9064) client tools not recognizing BINDDN from ldap.conf
by fabrice.ducos＠gmail.com 18 Aug '19

18 Aug '19

Full_Name: Fabrice Ducos Version: 2.4.48 OS: OSX 10.14.6 Mojave URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.110.219.170) I have installed OpenLDAP 2.4.48 from sources with SASL support. For the moment, I am not using SASL. I have created a small toy directory with a few records. I have got no problem reading it with the local utilities (slap cat, etc). Now I am in the course of playing with the client tools. In my ldap.conf, I have got the following directives: URI ldap://localhost BASE dc=myrealm,dc=mydomain,dc=org BINDDN cn=root,ou=users,dc=myrealm,dc=mydomain,dc=org (root is the name I gave to my the rootdn account in slapd.conf) The ldap.conf file has been put at the right place under /usr/local/etc/openldap When I perform the following command: ldapsearch -x -W -D 'cn=root,ou=users,dc=myrealm,dc=mydomain,dc=org' (with -x to force a simple binding) I get the results I expect from the directory, starting from BASE (no need for a -b option). However, when I test: ldapsearch -x -W (with -D), I would expect to get the same result, the binding DN being set up from ldap.conf BINDDN. However, it fails: Enter LDAP Password: ldap_bind: Invalid credentials (49) (this is not a problem of password, otherwise it would also fail in the first test; I use the same password in both). I put the example files under incoming/binddn_2019-08-18 on your ftp server. The passwords are unencrypted in these sample files (encryption of passwords in another topic), but it doesn't explain why the root password from slapd.conf is recognised with -W -D and not with -W alone. Thank for your assistance.

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by vporof＠mozilla.com 15 Aug '19

15 Aug '19

That's good to know. Since we're completely in the dark on how to produce a reliable test case that exercises this crash, the hope was that fuzzing could inch us towards a solution. There's also the problem that we're observing these crashes on Windows 7 and x86-64 (at least for now), as evidenced by this report: = https://crash-stats.mozilla.org/signature/?signature=3Dmdb_cursor_put&_col= umns=3Dplatform&_columns=3Dcpu_arch&_sort=3D-date&page=3D1#reports Fuzzing on that platform is quite a bit more difficult since tooling is=20= lacklustre. Furthermore, we can't really try fuzzing under WSL and=20 Windows 10, since LMDB also doesn't actually work well under WSL, due to mmap on a 0-length file failing with ENOEXEC, also complicating things: https://github.com/microsoft/WSL/issues/3451 I'm not clear if Robins George (OP) observed this crash on a different platform, perhaps they can confirm? If fuzzing isn't a worthwhile exploration avenue, any suggestions for=20 what kind of tests might exercise a crash like this?

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by hyc＠symas.com 14 Aug '19

14 Aug '19

hyc(a)symas.com wrote: > vporof(a)mozilla.com wrote: >> It might be possible that even though RKV was built in debug mode, the >> backing sys crate isn't building LMDB itself this way. On a very first >> glance it looks like this is the case, always going for opt level 2: >> https://github.com/danburkert/lmdb-rs/blob/master/lmdb-sys/build.rs#L23 >> >> I'll have a closer look at the build process and see what's going on. >> >> Can you share your build process that resulted in LMDB debug functions >> being optimized away? Did you build using the fuzzer via `cargo afl`? >> Something else? > > I deleted the lmdb-rkv-sys-* directories from target/debug/build, edited > .cargo/registry/src/github.com-1ecc6299db9ec823/lmdb-rkv-sys-0.8.6/lmdb/libraries/liblmdb/mdb.c > and added #define MDB_DEBUG 3 at the top of the file, then reran the cargo build command. > > RUSTFLAGS="-Clink-arg=-fuse-ld=gold" cargo afl build -v Not really sure it's worth spending time on these fuzzer results. Basically you're feeding corrupted database files into LMDB, and it is hitting an assert because it sees that the structure is corrupted. Working as designed, in other words. -- -- 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#9037) observing crash in mdb_cursor_put()
by hyc＠symas.com 14 Aug '19

14 Aug '19

vporof(a)mozilla.com wrote: > It might be possible that even though RKV was built in debug mode, the > backing sys crate isn't building LMDB itself this way. On a very first > glance it looks like this is the case, always going for opt level 2: > https://github.com/danburkert/lmdb-rs/blob/master/lmdb-sys/build.rs#L23 > > I'll have a closer look at the build process and see what's going on. > > Can you share your build process that resulted in LMDB debug functions > being optimized away? Did you build using the fuzzer via `cargo afl`? > Something else? I deleted the lmdb-rkv-sys-* directories from target/debug/build, edited .cargo/registry/src/github.com-1ecc6299db9ec823/lmdb-rkv-sys-0.8.6/lmdb/libraries/liblmdb/mdb.c and added #define MDB_DEBUG 3 at the top of the file, then reran the cargo build command. RUSTFLAGS="-Clink-arg=-fuse-ld=gold" cargo afl build -v -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs