openldap-bugs April 2015

openldap-bugs@openldap.org

29 participants
104 discussions

Re: (ITS#8116) [PATCH] ldapsearch: print 'SyncInfo Received' as a comment.
by hyc＠symas.com 29 Apr '15

29 Apr '15

linuxgeek(a)gmail.com wrote: > Full_Name: Thomas Cort > Version: HEAD > OS: Mac OS X 10.10.3 > URL: ftp://ftp.openldap.org/incoming/thomas-cort-150428.patch > Submission from: (NULL) (96.46.34.154) > > > When the -Esync command line option is used and a Sync Info > Message (RFC4533) is received, ldapsearch simply prints > 'SyncInfo Received' to STDOUT. This causes LDIF parsers and > other tools which consume ldapsearch output to break on invalid > input. > > Change this informational message to be conveyed as a comment. > Additionally, hide the message when comments are disabled (-LL or > -LLL). If we're going to the trouble of patching this bit of code, I wonder if it would be worthwhile to actually print the contents of the syncinfo as well. Maybe a hex dump. > > I uploaded the patch to ftp.openldap.org as thomas-cort-150428.patch > > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch(es) were > developed by Thomas Cort <linuxgeek(a)gmail.com>. I have not assigned rights > and/or interest in this work to any party. > > I, Thas C Cort, 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#8118) [PATCH] tool_write_ldif: flush stdout
by linuxgeek＠gmail.com 29 Apr '15

29 Apr '15

Full_Name: Thomas Cort Version: HEAD OS: Mac OS X 10.10.3 URL: ftp://ftp.openldap.org/incoming/thomas-cort-150429.patch Submission from: (NULL) (96.46.34.154) The LDIF output wasn't being explicitly flushed. In certain scenarios, such as piping the output of a persistent ldapsearch to node.js v0.12 on Mac OS X 10.10.3, the output is unavailable to the process consuming the search results until some operating system limit is reached (8192 bytes for example) and it is automatically flushed. This can leave the tail end of persistent search results in an operating system buffer for a long time (until enough output has accumulated for the OS to flush it). Explicitly call flush so that the output is immediately available. I uploaded the patch to ftp.openldap.org as thomas-cort-150429.patch The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Thomas Cort <linuxgeek(a)gmail.com>. I have not assigned rights and/or interest in this work to any party. I, Thomas Cort, 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#8117) Bugs related to key-size in lmdb and backend
by hyc＠symas.com 29 Apr '15

29 Apr '15

Leonid Yuriev wrote: > > > 29.04.2015 16:06, Howard Chu пишет: >> leo(a)yuriev.ru wrote: >>> Full_Name: Leo Yuriev >>> Version: 2.4-HEAD >>> OS: RHEL7 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (31.130.36.33) >>> >>> >>> 1) LMDB: On 64-bit systems, in some cases mdb_cmp_int() could be >>> called instead >>> of mdb_cmp_long(), when key.mv_size == 8. >>> To reproduce this is enough add an assertion-check for key.size == >>> sizeof(int) >>> into mdb_cmp_int().A%A >> >> You need to provide more details than this. mdb_cmp_int() isn't even >> used on regular databases, only on DUPSORT databases. Provide actual >> code reproducing the issue. >> > this is enough: > - add assert(a->mv_key_size == sizeof(size_t)) into mdb_cmp_long() > - make all test > - see a coredump OK, fixed in git. For the record, this affected MDB_INTEGERDUP, not MDB_INTEGERKEY. >>> 3) lmdb-backend: >>> AttributeDescription->ad_type->sat_equality->smr_indexer() >>> could generate a 5-byte sized ks.s. I can just imagine what this can >>> create a >>> many problems. For instance, when I adds the control for key size, it >>> breaks >>> test017-syncreplication-refresh. But I am not tested more. >> >> Not a bug, indexer keys are padded to 8 bytes. > > There is just NOT padded, I am sure. > Also this is reason for unaligned-access in mdb_cmp_int() and > mdb_cmp_long(). > It is similar to reproduce, just assert + make test. Ah yes, the padding is currently only done on platforms that don't allow unaligned access to ints (e.g. Sparc) git rev e2a7617d17368b5787fc24fbd017623d00fe162b > Seems that bugs together could break ordering of entries, this is > detected by loop over all entries with mdb_cursor_get(..., MDB_NEXT) and > comparing keys from previous step. > All of this I was found today, during developing a mdb_chk tool. -- -- 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#8117) Bugs related to key-size in lmdb and backend
by leo＠yuriev.ru 29 Apr '15

29 Apr '15

29.04.2015 17:07, Howard Chu пишет: > leo(a)yuriev.ru wrote: >> Code style and code quality of OpenLDAP - is just a trash (IMHO). > > And your opinion is worth what, exactly? > > This code has come a long way since I started working on it in 1998. > Frankly I had the same opinion then, as you do now. But rather than > complain, I fixed the problems I found. There are probably still many > more of course, in corners of the code I have never looked at. > > If you think you can do better, prove it - take a copy of UMich LDAP > 3.3, where OpenLDAP started from, and bring it up to date with LDAPv3 > and make it match OpenLDAP's performance and features. I look forward > to reviewing your result. > > Until you do that, you have no basis for your pointless insults. > I have no intention to offend or humiliate you. It's hard to say what I would do in your position, but I have my opinion (as I believe informed) about the quality of the code. Whether are necessary to correct the situation, and how to do it - you decide. I think the first important step - to acknowledge the problem and put into a goals. For my part I can say that I must to achieve stability, at least in our scenarios. Regards, Leonid.

1 0

Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by hyc＠symas.com 29 Apr '15

29 Apr '15

leo(a)yuriev.ru wrote: > Code style and code quality of OpenLDAP - is just a trash (IMHO). And your opinion is worth what, exactly? This code has come a long way since I started working on it in 1998. Frankly I had the same opinion then, as you do now. But rather than complain, I fixed the problems I found. There are probably still many more of course, in corners of the code I have never looked at. If you think you can do better, prove it - take a copy of UMich LDAP 3.3, where OpenLDAP started from, and bring it up to date with LDAPv3 and make it match OpenLDAP's performance and features. I look forward to reviewing your result. Until you do that, you have no basis for your pointless insults. -- -- 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#8117) Bugs related to key-size in lmdb and backend
by leo＠yuriev.ru 29 Apr '15

29 Apr '15

29.04.2015 16:06, Howard Chu пишет: > leo(a)yuriev.ru wrote: >> Full_Name: Leo Yuriev >> Version: 2.4-HEAD >> OS: RHEL7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (31.130.36.33) >> >> >> 1) LMDB: On 64-bit systems, in some cases mdb_cmp_int() could be >> called instead >> of mdb_cmp_long(), when key.mv_size == 8. >> To reproduce this is enough add an assertion-check for key.size == >> sizeof(int) >> into mdb_cmp_int().A%A > > You need to provide more details than this. mdb_cmp_int() isn't even > used on regular databases, only on DUPSORT databases. Provide actual > code reproducing the issue. > this is enough: - add assert(a->mv_key_size == sizeof(size_t)) into mdb_cmp_long() - make all test - see a coredump > >> 2) LMDB: There is no any checking for invalid key-size for >> MDB_INTEGERKEY and >> MDB_INTEGERDUP. Therefore, for example, mdb_cursor_put() accepts a >> key.size == 1 >> and so forth. > > Not a bug, MDB_INTEGERKEY is documented to only be used with > word-sized keys. Ok, let it be "a feature" ;) >> 3) lmdb-backend: >> AttributeDescription->ad_type->sat_equality->smr_indexer() >> could generate a 5-byte sized ks.s. I can just imagine what this can >> create a >> many problems. For instance, when I adds the control for key size, it >> breaks >> test017-syncreplication-refresh. But I am not tested more. > > Not a bug, indexer keys are padded to 8 bytes. There is just NOT padded, I am sure. Also this is reason for unaligned-access in mdb_cmp_int() and mdb_cmp_long(). It is similar to reproduce, just assert + make test. Seems that bugs together could break ordering of entries, this is detected by loop over all entries with mdb_cursor_get(..., MDB_NEXT) and comparing keys from previous step. All of this I was found today, during developing a mdb_chk tool. >> P.S. >> It is a one more nice rebus from Howard ;) > > Thanks for the irrelevant editorials. It might even be amusing if they > were true, but mostly they just demonstrate your inexperience. > Code style and code quality of OpenLDAP - is just a trash (IMHO). By functional is a 100 times simple than (for instance) Linux/FreeBSD/Windows kernel, or PostgreSQL. But simultaneously it is 100 times harder to find and fix bugs or make a some progress. You can't hide the obvious.

1 0

Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by hyc＠symas.com 29 Apr '15

29 Apr '15

leo(a)yuriev.ru wrote: > Full_Name: Leo Yuriev > Version: 2.4-HEAD > OS: RHEL7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (31.130.36.33) > > > 1) LMDB: On 64-bit systems, in some cases mdb_cmp_int() could be called instead > of mdb_cmp_long(), when key.mv_size == 8. > To reproduce this is enough add an assertion-check for key.size == sizeof(int) > into mdb_cmp_int().A%A You need to provide more details than this. mdb_cmp_int() isn't even used on regular databases, only on DUPSORT databases. Provide actual code reproducing the issue. > 2) LMDB: There is no any checking for invalid key-size for MDB_INTEGERKEY and > MDB_INTEGERDUP. Therefore, for example, mdb_cursor_put() accepts a key.size == 1 > and so forth. Not a bug, MDB_INTEGERKEY is documented to only be used with word-sized keys. > 3) lmdb-backend: AttributeDescription->ad_type->sat_equality->smr_indexer() > could generate a 5-byte sized ks.s. I can just imagine what this can create a > many problems. For instance, when I adds the control for key size, it breaks > test017-syncreplication-refresh. But I am not tested more. Not a bug, indexer keys are padded to 8 bytes. > P.S. > It is a one more nice rebus from Howard ;) Thanks for the irrelevant editorials. It might even be amusing if they were true, but mostly they just demonstrate your inexperience. -- -- 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#8117) Bugs related to key-size in lmdb and backend
by leo＠yuriev.ru 29 Apr '15

29 Apr '15

Full_Name: Leo Yuriev Version: 2.4-HEAD OS: RHEL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.130.36.33) 1) LMDB: On 64-bit systems, in some cases mdb_cmp_int() could be called instead of mdb_cmp_long(), when key.mv_size == 8. To reproduce this is enough add an assertion-check for key.size == sizeof(int) into mdb_cmp_int().A%A 2) LMDB: There is no any checking for invalid key-size for MDB_INTEGERKEY and MDB_INTEGERDUP. Therefore, for example, mdb_cursor_put() accepts a key.size == 1 and so forth. 3) lmdb-backend: AttributeDescription->ad_type->sat_equality->smr_indexer() could generate a 5-byte sized ks.s. I can just imagine what this can create a many problems. For instance, when I adds the control for key size, it breaks test017-syncreplication-refresh. But I am not tested more. P.S. It is a one more nice rebus from Howard ;)

1 0

(ITS#8116) [PATCH] ldapsearch: print 'SyncInfo Received' as a comment.
by linuxgeek＠gmail.com 28 Apr '15

28 Apr '15

Full_Name: Thomas Cort Version: HEAD OS: Mac OS X 10.10.3 URL: ftp://ftp.openldap.org/incoming/thomas-cort-150428.patch Submission from: (NULL) (96.46.34.154) When the -Esync command line option is used and a Sync Info Message (RFC4533) is received, ldapsearch simply prints 'SyncInfo Received' to STDOUT. This causes LDIF parsers and other tools which consume ldapsearch output to break on invalid input. Change this informational message to be conveyed as a comment. Additionally, hide the message when comments are disabled (-LL or -LLL). I uploaded the patch to ftp.openldap.org as thomas-cort-150428.patch The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Thomas Cort <linuxgeek(a)gmail.com>. I have not assigned rights and/or interest in this work to any party. I, Thas C Cort, 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#8115) Adding passwd hash schemes
by quanah＠zimbra.com 28 Apr '15

28 Apr '15

--On Tuesday, April 28, 2015 3:33 PM +0000 bruno_haleblian(a)carrefour.com wrote: > Supposing I can translate it to C, what is the best and cleanest way to > integrate this specific scheme? > Is there an "overlay way" to do this? > Do I Have to hack into passwd.c in lutils? > Has this kind of work already been done? The ITS system is for reporting bugs, not asking usage questions about the software. Please re-direct your questions to openldap-technical(a)openldap.org. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2015