openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs