- openldap-bugs - openldap.org

(ITS#8121) mention LDAP_SASL_SIMPLE in ldap_bind.3
by ryan＠openldap.org 30 Apr '15

30 Apr '15

Full_Name: Ryan Tandy Version: OS: URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan In IRC, txtd noted that both ldap_simple_bind and ldap_bind are marked as deprecated in ldap.h, and asked about the recommended way to perform a simple bind. OpenLDAP code uses ldap_sasl_bind(LDAP_SASL_SIMPLE), but that flag is not mentioned in any man page.

1 0

(ITS#8120) CHECK_CSN unreliable as final check is after mutex is unlocked
by quanah＠openldap.org 30 Apr '15

30 Apr '15

Full_Name: Quanah Gibson-Mount Version: 2.4.40 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) The CHECK_CSN ifdef code is unreliable as the final check on the CSN's is done after the mutex is unlocked, while all of the other checks are done after the mutex is locked. This can cause the assert to trigger on valid CSNs.

1 0

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

30 Apr '15

Leonid Yuriev wrote: > 29.04.2015 21:55, Howard Chu пишет: >> Leonid Yuriev wrote: >> >>> But what about 5-bytes keys from indexer? >>> - How ones should be compared, as a 4-byte int without MSB, or as a >>> padded 8-byte long? >> >> The indexer doesn't use MDB_INTEGER so your question is irrelevant. >> > OK, but then - what is the purpose of MDB_INTEGERDUP in > mdb_attr_dbs_open()? > > flags = MDB_DUPSORT|MDB_DUPFIXED|MDB_INTEGERDUP; > if ( !(slapMode & SLAP_TOOL_READONLY) ) > flags |= MDB_CREATE; > > Think it is not necessary, is it? You really think so? Have you thought about what the actual *values* are in an index, instead of just the keys? Anyway, this ITS is resolved. Thank you for reporting the bug. If you want to ask further questions about how the indexer works take it to openldap-devel. -- -- 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 21:55, Howard Chu пишет: > Leonid Yuriev wrote: > >> But what about 5-bytes keys from indexer? >> - How ones should be compared, as a 4-byte int without MSB, or as a >> padded 8-byte long? > > The indexer doesn't use MDB_INTEGER so your question is irrelevant. > OK, but then - what is the purpose of MDB_INTEGERDUP in mdb_attr_dbs_open()? flags = MDB_DUPSORT|MDB_DUPFIXED|MDB_INTEGERDUP; if ( !(slapMode & SLAP_TOOL_READONLY) ) flags |= MDB_CREATE; Think it is not necessary, is it? Leonid.

1 0

Re: (ITS#8119) ldapsearch: put empty line after result not before next result
by michael＠stroeder.com 29 Apr '15

29 Apr '15

linuxgeek(a)gmail.com wrote: > ldapsearch outputs LDAP results in a loop. The LDIF separator isn't printed > after the result is printed. It's printed before the next result is printed. > This subtlety causes a problem for a program consuming the output of a > persistent ldapsearch (-Esync=rp). Sorry, but anyone who wants to implement a robust syncrepl client should not rely on ldapsearch command-line tool for that job. IMO it will never really fit the requirements. Use a decent LDAP module for your programming language. Ciao, Michael.

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 19:35, Howard Chu пишет: >> Ah yes, the padding is currently only done on platforms that don't >> allow unaligned access to ints (e.g. Sparc) >> >> git rev e2a7617d17368b5787fc24fbd017623d00fe162b > But what about 5-bytes keys from indexer? > - How ones should be compared, as a 4-byte int without MSB, or as a > padded 8-byte long? The indexer doesn't use MDB_INTEGER so your question is irrelevant. > - Where is the padding code? The code is in the git commit ID I already posted in my previous reply. -- -- 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#8119) ldapsearch: put empty line after result not before next result
by linuxgeek＠gmail.com 29 Apr '15

29 Apr '15

Full_Name: Thomas Cort Version: HEAD OS: 10.10.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (96.46.34.154) ldapsearch outputs LDAP results in a loop. The LDIF separator isn't printed after the result is printed. It's printed before the next result is printed. This subtlety causes a problem for a program consuming the output of a persistent ldapsearch (-Esync=rp). It has no way of knowing the current result has been fully output until the separator is printed (when the next result comes in), which could take a long time if there are no changes going on. I think the newline should be printed at the end of the for-loop (after the result is printed), not at the beginning (when the next result is received). I tried moving the putchar('\n') to the end of the for-loop. The output is the same for some simple searches I tried and the test suite passes. I'm hesitant to submit that as a patch because I think there might be some subtle edge cases I haven't hit where an extra newline would be inserted or omitted. Any ideas from someone who understands the code?

1 0

Re: (ITS#8118) [PATCH] tool_write_ldif: flush stdout
by linuxgeek＠gmail.com 29 Apr '15

29 Apr '15

--089e0160bf101f3e240514e06e96 Content-Type: text/plain; charset=UTF-8 > A more suitable patch might be one that flushes once when all currently > available messages have been processed in ldapsearch.c. > I.e., after the for-loop in dosearch() completes. Here's an updated patch: ftp://ftp.openldap.org/incoming/thomas-cort-150429b.patch --089e0160bf101f3e240514e06e96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>> A more suitable patch might be one that flushes = once when all currently</div><div>> available messages have been process= ed in ldapsearch.c.</div><div>> I.e., after the for-loop in dosearch() c= ompletes.<br><br></div><div>Here's an updated patch:</div><div><br></di= v><div><a href=3D"ftp://ftp.openldap.org/incoming/thomas-cort-150429b.patch= ">ftp://ftp.openldap.org/incoming/thomas-cort-150429b.patch</a></div><div c= lass=3D"gmail_extra"><br></div></div> --089e0160bf101f3e240514e06e96--

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 19:35, Howard Chu пишет: > Leonid Yuriev wrote: >> 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. Yes, I was made same local changes few hours ago. This fixs miss-call for mdb_cmp_long(). But what about 5-bytes keys from indexer? - How ones should be compared, as a 4-byte int without MSB, or as a padded 8-byte long? - Where is the padding code? Leonid.

1 0

Re: (ITS#8118) [PATCH] tool_write_ldif: flush stdout
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-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. That totally defeats the purpose of using stdio - which is, to generate buffered output and avoid excessive numbers of system calls. Rejecting this patch. A more suitable patch might be one that flushes once when all currently available messages have been processed in ldapsearch.c. I.e., after the for-loop in dosearch() completes. > > 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. > > -- -- 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#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

Re: (ITS#8115) Adding passwd hash schemes
by michael＠stroeder.com 28 Apr '15

28 Apr '15

This is a cryptographically signed message in MIME format. --------------ms080402030704010800040907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable bruno_haleblian(a)carrefour.com wrote: > My goal is to import millions of accounts from a drupal DB to OpenLDAP.= > preserving existing passwords. I plan to write a SQL to ldif script for= that. > Problem : > These accounts come with a non-standard passwd hash scheme. I've attach= ed drupal > link to source code in PHP. > Although it uses standard SHA512 and base64, the algo is a variant of m= ultiple > sha512 + salt iterations. Looks like there's no way to convert to {SSHA= 512} or > something standard. > 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? > > Goal : getting userPassword=3D{DRUP7}$S$DNbBTrkalsPChLsqajHUQS18pBBxzST= QW0310SzivTy7HDQ.zgyG > to be supported 1. The password hash looks a bit like a crypt(3) hashing scheme. You shou= ld=20 consult the crypt(3) man page on this system. There are {crypt} schemes w= hich=20 uses several rounds. 2. You will find several such password modules in the source distribution= in=20 directory contrib/slapd-modules/passwd/ Ciao, Michael. --------------ms080402030704010800040907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4 uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih 34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22 A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3 6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyODE0NDIxMVowLwYJKoZIhvcNAQkEMSIE IL8TDseT/devnjkz2gAIs7YDwtLRWVTSaQWUUBMLiUYNMGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq hkiG9w0BAQEFAASCAQB3ev7x7TOAo5Uo1WsZdCw/m7Ixd1+pXVVYwOXZ0KBQ/p2xyEqyA/A2 ag92TnXYA3F7BYe07X+nlEtF0ZNDC7HIv33Y36sHR2TxRAHTk+cM9wKdEuYOPMMvpDyoolys wgt4JrdY6O9TB+oJ0DUNG7QEHIOTYMe4jxs9u+XvaNBwXxGGDVc2VnvMaU219cm3X0QF3UaZ fSHrcTcyi19KHTIbfBWftKZAL9tHp0UBppkxfCVE8FMfpaa9zgRS9UStw+Ih0p8nhL344ODt /IpXbjY5rBPpDRKRJ4ND3XQysdjrGiH21IXKKeQmMybzjL9CNGbVqAYL7T2A/cLKhnYLiw0f AAAAAAAA --------------ms080402030704010800040907--

1 0

(ITS#8115) Adding passwd hash schemes
by bruno_haleblian＠carrefour.com 28 Apr '15

28 Apr '15

Full_Name: Bruno HALEBLIAN Version: 2.4.40 > OS: RH/CentOS 6.x URL: https://api.drupal.org/api/drupal/includes!password.inc/function/_password_… Submission from: (NULL) (195.154.81.10) Hi, My goal is to import millions of accounts from a drupal DB to OpenLDAP. preserving existing passwords. I plan to write a SQL to ldif script for that. Problem : These accounts come with a non-standard passwd hash scheme. I've attached drupal link to source code in PHP. Although it uses standard SHA512 and base64, the algo is a variant of multiple sha512 + salt iterations. Looks like there's no way to convert to {SSHA512} or something standard. 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? Goal : getting userPassword={DRUP7}$S$DNbBTrkalsPChLsqajHUQS18pBBxzSTQW0310SzivTy7HDQ.zgyG to be supported Regards, BHa.

1 0

Re: (ITS#8105) [PATCH] slaptest doesn't convert perlModuleConfig lines
by hyc＠symas.com 27 Apr '15

27 Apr '15

Jan Synacek wrote: > Howard Chu <hyc(a)symas.com> writes: >> Looks OK. One minor nit - we discourage using strlen() (or most of the >> libc str* functions, really). We particularly discourage runtime >> calculations on compile-time constants (including string constants) - >> use the STRLENOF() macro instead. > > Done. > Thanks, in git 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

Re: (ITS#8105) [PATCH] slaptest doesn't convert perlModuleConfig lines
by jsynacek＠redhat.com 27 Apr '15

27 Apr '15

--=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Howard Chu <hyc(a)symas.com> writes: > Jan Synacek wrote: >> Howard Chu <hyc(a)symas.com> writes: >> >>> Jan Synacek wrote: >>>> Howard Chu <hyc(a)symas.com> writes: >>>> >>>>> jsynacek(a)redhat.com wrote: >>>>>> Full_Name: Jan Synacek >>>>>> Version: master >>>>>> OS: GNU/Linux >>>>>> URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150415-ba= ck-perl-correctly-convert-perlModuleConfig.patch >>>>>> Submission from: (NULL) (213.175.37.10) >>>>>> >>>>>> >>>>>> When using the perl backend, slaptest doesn't convert perlModuleConf= ig lines >>>>>> from slapd.conf to slapd.d. >>>>>> >>>>>> A simple reproducer can be found at >>>>>> https://jsynacek.fedorapeople.org/openldap/back-perl.sh >>>>>> >>>>>> >>>>> Thanks, added to git master >>>> >>>> I misunderstood the semantics of perlModuleConfig when given multiple >>>> arguments, so the patch isn't quite correct. I'm sorry for the >>>> confusion. The fix can be found at: >>>> >>>> URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150424-More= -for-ITS-8105.patch >>>> >>>> Please note that I'm not aware of any internal functions that I can use >>>> to flatten a list of strings. If there are some, or if there is a bett= er >>>> way to fix the issue, please advice, I'll simplify the patch. >>>> >>> Hi Jan, there's no need to muck with the list of strings, just use >>> c->line instead of c->argv. >> >> Thank you for your advice! I've simplified the patch (url stays the same= ). > > Looks OK. One minor nit - we discourage using strlen() (or most of the=20 > libc str* functions, really). We particularly discourage runtime=20 > calculations on compile-time constants (including string constants) -=20 > use the STRLENOF() macro instead. Done. =2D-=20 Jan Synacek Software Engineer, Red Hat --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVPgvMAAoJEL3BmMJQOtjBC/cQAK3bicCb/k7Y47Jwt8hgIp7A 2+jHmMtIwVdA7sK7f26dPlwATUxtYXdXwewTJF8+t+wUg99cNEmgF0c/7clpEVJn 7lwOTdM5aJj5WDarXLYBpOnVoXNCP9aHTigAAe6wuRCHxeIclbqf5yd8wxEELDkl piM6KkdWKqKlBY/hybD6+JI+hbXSFsHJfIdSudq+uVZwyDLjdjy3SPjoNiSZxSUi S+h7CAt+d384KXX8aEGq9hUe5K2vvr3Yr83Gelm6w6xN4/aDFQZ75SHumsMPXrAe j5mGNDb1Y8mMcrzJ0Qc/6JT8JCbhHJEaHKLUxLeYOH1NFylqNFUA2kgYI5jsjVUE eMSXbb+pyKeWMbqUERNH6/tNS2t9rk/awJCj4o+xsRoK8DluUnP7tkSpTaDe4UqO itgxNhKCV9NPm5Ar3MbBJOVK+dBIgOM9VM+t5ju+MdpiDTuytnUgIvvaixWfP7Bg t8Q4t9U8u3gHoWyBdBnLVmwx7qq/BtPxqAt5uDv8mv9MyM9eeoDb4eaRhOe7sl2y 5s3bpBvOADks4dX5RpQ/SGUU5s/Fh/b2rAUrXqVxEkw5PipbTOBhx2LwKNVPnGhm SoLjQzm7fDEODFS7/jAWbzYsxQ6m8engNUpSi1rMt1PJbLzVrW2vaU6+1UG5eiaS IhBsZnx4E+WCfGoaUzxt =23Ho -----END PGP SIGNATURE----- --=-=-=--

1 0

Re: (ITS#8105) [PATCH] slaptest doesn't convert perlModuleConfig lines
by hyc＠symas.com 27 Apr '15

27 Apr '15

Jan Synacek wrote: > Howard Chu <hyc(a)symas.com> writes: > >> Jan Synacek wrote: >>> Howard Chu <hyc(a)symas.com> writes: >>> >>>> jsynacek(a)redhat.com wrote: >>>>> Full_Name: Jan Synacek >>>>> Version: master >>>>> OS: GNU/Linux >>>>> URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150415-back-perl-corr… >>>>> Submission from: (NULL) (213.175.37.10) >>>>> >>>>> >>>>> When using the perl backend, slaptest doesn't convert perlModuleConfig lines >>>>> from slapd.conf to slapd.d. >>>>> >>>>> A simple reproducer can be found at >>>>> https://jsynacek.fedorapeople.org/openldap/back-perl.sh >>>>> >>>>> >>>> Thanks, added to git master >>> >>> I misunderstood the semantics of perlModuleConfig when given multiple >>> arguments, so the patch isn't quite correct. I'm sorry for the >>> confusion. The fix can be found at: >>> >>> URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150424-More-for-ITS-8… >>> >>> Please note that I'm not aware of any internal functions that I can use >>> to flatten a list of strings. If there are some, or if there is a better >>> way to fix the issue, please advice, I'll simplify the patch. >>> >> Hi Jan, there's no need to muck with the list of strings, just use >> c->line instead of c->argv. > > Thank you for your advice! I've simplified the patch (url stays the same). Looks OK. One minor nit - we discourage using strlen() (or most of the libc str* functions, really). We particularly discourage runtime calculations on compile-time constants (including string constants) - use the STRLENOF() macro instead. -- -- 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