- openldap-bugs - openldap.org

Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by h.b.furuseth＠usit.uio.no 15 Nov '14

15 Nov '14

__sync_synchronize() needs an #ifdef around it. #ifdef __GNUC__, or something more general? Not sure what to do for the #else. We could mostly avoid using mm_txnid when the lockfile is initialized and use mti_txnid instead (e.g. in pick_meta). And penalize MDB_NOLOCK with some sync call in the #else. -- Hallvard

1 0

(ITS#7982) Add tls cipher suite, protocol to ldapsearch debug logging
by quanah＠openldap.org 14 Nov '14

14 Nov '14

Full_Name: Quanah Gibson-Mount Version: 2.4.40 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.14.70.124) Support for logging the TLS protocol and cipher suite being used was added for slapd connections in ITS#7683. However, there's no way from the client side (for those who don't have access to the LDAP server) to see what protocol and cipher suite were negotiated. This can be useful information to have on hand.

1 0

(ITS#7981) Feature request: Crypt scheme in pwdPolicy
by michael＠stroeder.com 14 Nov '14

14 Nov '14

Full_Name: Version: OS: URL: Submission from: (NULL) (79.219.125.95) It would be handy if the password storage/crypt scheme could be specified in a pwdPolicy entry. LDAP Modify Password Ext.Op. should use this information instead of global configuration olcPasswordHash. Rationale: There might be in one database several different account types needed with pwdPolicySubentry pointing to separate pwdPolicy entries. Example: - Normal account with strongly hashed password for direct LDAP simple bind - Clear-text userPassword for WLAN authenticated through RADIUS server Ideally this should be standardized when the ldapext WG is revived. ;-)

1 0

(ITS#7980) LMDB added support for user context in compare function
by rouzier＠gmail.com 13 Nov '14

13 Nov '14

Full_Name: James Rouzier Version: 2.4 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.222.129.11) https://github.com/rouzier/openldap/commit/33f1dc8be4a8503e78930f130ff9c8e5… I added support for user supplied context for lmdb in the compare functions. This make it much easier to integrate with scripting languages. -- 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 James Rouzier <rouzier(a)gmail.com>. I have not assigned rights and/or interest in this work to any party. I, James Rouzier, 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#7979) mozNSS does not process TLS_PROTOCOL_MIN
by hyc＠symas.com 13 Nov '14

13 Nov '14

Mark Reynolds wrote: > > On 11/12/2014 04:56 PM, Howard Chu wrote: >> mreynolds(a)redhat.com wrote: >>> Full_Name: Mark Reynolds >>> Version: 2.4.40 >>> OS: Fedora 20 >>> URL: ftp://ftp.openldap.org/incoming/mark-reynolds-141112.patch >>> Submission from: (NULL) (174.60.44.17) >>> >>> >>> Currently there is no check for TLS_PROTOCOL_MIN in the mozNSS code. >>> mozNSS >>> defaults to SSLv3/TLS1.0 which is no longer considered secure. If a >>> client only >>> supports TLSv1.1 and up, the openldap ldapsearch will fail to connect >>> over SSL. >>> >>> ldapsearch -H "ldaps://localhost.localdomain:636" -b "" -s base >>> objectclass=* >>> >>> or >>> >>> LDAPTLS_PROTOCOL_MIN=3.2 ldapsearch -H >>> "ldaps://localhost.localdomain:636" -b "" >>> -s base objectclass=* >>> >>> The fix is to grab the supported version range from NSS, adjust the >>> minimum >>> range if TLS_PROTOCOL_MIN is set, and then set the NSS default range >>> with the >>> min and max versions. >> >> Thanks for the patch. I'm concerned because I see you adding MozNSS >> constants (SSL_LIBRARY_VERSION_TLS_1_2) in code that expects libldap >> values (LDAP_OPT_X_TLS_PROTOCOL_TLS1_2). I haven't checked; they may >> well be identical values. But please make sure, and add a comment to >> that effect, so that it's clear that setting lt_protocol_min is >> actually doing what's expected. > Thanks for the feedback Howard. Yes, the SSL versions are the same in > NSS & openldap. I have uploaded a new patch with the requested > comments: mark-reynolds-141113.patch Thanks, committed to master. > On a side note, we are pushing the NSS team to update the NSS API to > provide the SSL version to version string mapping. So we will be able > to remove the hardcoded map(pvers) in openldap once this get addressed. Great. Nice to see they're finally addressing their usability issues. -- -- 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#7979) mozNSS does not process TLS_PROTOCOL_MIN
by mreynolds＠redhat.com 13 Nov '14

13 Nov '14

On 11/12/2014 04:56 PM, Howard Chu wrote: > mreynolds(a)redhat.com wrote: >> Full_Name: Mark Reynolds >> Version: 2.4.40 >> OS: Fedora 20 >> URL: ftp://ftp.openldap.org/incoming/mark-reynolds-141112.patch >> Submission from: (NULL) (174.60.44.17) >> >> >> Currently there is no check for TLS_PROTOCOL_MIN in the mozNSS code. >> mozNSS >> defaults to SSLv3/TLS1.0 which is no longer considered secure. If a >> client only >> supports TLSv1.1 and up, the openldap ldapsearch will fail to connect >> over SSL. >> >> ldapsearch -H "ldaps://localhost.localdomain:636" -b "" -s base >> objectclass=* >> >> or >> >> LDAPTLS_PROTOCOL_MIN=3.2 ldapsearch -H >> "ldaps://localhost.localdomain:636" -b "" >> -s base objectclass=* >> >> The fix is to grab the supported version range from NSS, adjust the >> minimum >> range if TLS_PROTOCOL_MIN is set, and then set the NSS default range >> with the >> min and max versions. > > Thanks for the patch. I'm concerned because I see you adding MozNSS > constants (SSL_LIBRARY_VERSION_TLS_1_2) in code that expects libldap > values (LDAP_OPT_X_TLS_PROTOCOL_TLS1_2). I haven't checked; they may > well be identical values. But please make sure, and add a comment to > that effect, so that it's clear that setting lt_protocol_min is > actually doing what's expected. Thanks for the feedback Howard. Yes, the SSL versions are the same in NSS & openldap. I have uploaded a new patch with the requested comments: mark-reynolds-141113.patch On a side note, we are pushing the NSS team to update the NSS API to provide the SSL version to version string mapping. So we will be able to remove the hardcoded map(pvers) in openldap once this get addressed. Regards, Mark >> >> Also updated the NSS version string map table to support up to TLSv1.3 >

1 0

Re: (ITS#7979) mozNSS does not process TLS_PROTOCOL_MIN
by hyc＠symas.com 12 Nov '14

12 Nov '14

mreynolds(a)redhat.com wrote: > Full_Name: Mark Reynolds > Version: 2.4.40 > OS: Fedora 20 > URL: ftp://ftp.openldap.org/incoming/mark-reynolds-141112.patch > Submission from: (NULL) (174.60.44.17) > > > Currently there is no check for TLS_PROTOCOL_MIN in the mozNSS code. mozNSS > defaults to SSLv3/TLS1.0 which is no longer considered secure. If a client only > supports TLSv1.1 and up, the openldap ldapsearch will fail to connect over SSL. > > ldapsearch -H "ldaps://localhost.localdomain:636" -b "" -s base objectclass=* > > or > > LDAPTLS_PROTOCOL_MIN=3.2 ldapsearch -H "ldaps://localhost.localdomain:636" -b "" > -s base objectclass=* > > The fix is to grab the supported version range from NSS, adjust the minimum > range if TLS_PROTOCOL_MIN is set, and then set the NSS default range with the > min and max versions. Thanks for the patch. I'm concerned because I see you adding MozNSS constants (SSL_LIBRARY_VERSION_TLS_1_2) in code that expects libldap values (LDAP_OPT_X_TLS_PROTOCOL_TLS1_2). I haven't checked; they may well be identical values. But please make sure, and add a comment to that effect, so that it's clear that setting lt_protocol_min is actually doing what's expected. > > Also updated the NSS version string map table to support up to TLSv1.3 -- -- 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#7977) Supported PBKDF2-SHA256 and PBKDF2-SHA512
by hyc＠symas.com 12 Nov '14

12 Nov '14

Looking over this patch https://www.osstech.co.jp/download/hamano/openldap-pbkdf2_nettle.patch You've added a new contributor: @@ -97,3 +99,5 @@ top-level directory of the distribution or, alternatively, at # ACKNOWLEDGEMENT This work was initially developed by HAMANO Tsukasa <hamano(a)osstech.co.jp> +Contributor: +Luca Bruno(lucab) We cannot accept 3rd party submissions; Luca will have to submit any relevant patches directly to us, along with a corresponding IPR statement as outlined in our Contributors guidelines. -- -- 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#7979) mozNSS does not process TLS_PROTOCOL_MIN
by mreynolds＠redhat.com 12 Nov '14

12 Nov '14

Full_Name: Mark Reynolds Version: 2.4.40 OS: Fedora 20 URL: ftp://ftp.openldap.org/incoming/mark-reynolds-141112.patch Submission from: (NULL) (174.60.44.17) Currently there is no check for TLS_PROTOCOL_MIN in the mozNSS code. mozNSS defaults to SSLv3/TLS1.0 which is no longer considered secure. If a client only supports TLSv1.1 and up, the openldap ldapsearch will fail to connect over SSL. ldapsearch -H "ldaps://localhost.localdomain:636" -b "" -s base objectclass=* or LDAPTLS_PROTOCOL_MIN=3.2 ldapsearch -H "ldaps://localhost.localdomain:636" -b "" -s base objectclass=* The fix is to grab the supported version range from NSS, adjust the minimum range if TLS_PROTOCOL_MIN is set, and then set the NSS default range with the min and max versions. Also updated the NSS version string map table to support up to TLSv1.3

1 0

Re: (ITS#7832) Proposing ppolicy extended module for OpenLDAP
by dcoutadeur＠linagora.com 12 Nov '14

12 Nov '14

Hi, The ppm module is still alive, and is evolving. Last version is 1.2, and source code is now available on Github : https://github.com/davidcoutadeur/ppm There are also plans to package it. If anybody is interrested, I am always glad to hear about comments, ideas, improvements,... Sincerely, David

1 0

Re: (ITS#7977) Supported PBKDF2-SHA256 and PBKDF2-SHA512
by hamano＠osstech.co.jp 07 Nov '14

07 Nov '14

Hi, Please merge the additional patch: https://www.osstech.co.jp/download/hamano/openldap-pbkdf2_nettle.patch This patch include nettle support and fix a issue. https://github.com/hamano/openldap-pbkdf2/pull/4 https://github.com/hamano/openldap-pbkdf2/pull/3 Thank you. At Wed, 05 Nov 2014 11:57:33 +0000, Howard Chu wrote: > > Tsukasa HAMANO wrote: > > Hi, Howard > > > > At Wed, 05 Nov 2014 09:32:43 +0000, > > Howard Chu wrote: > >> > >> Any particular reason you've decreased the iterations from 60000 to 10000? > >> > > > > It was too slow when stretching 60000 on powerless server. > > My tiny VM needed over 1sec if iterate 60000 by PBKDF2-SHA512. > > RFC recommends more than 1000 iterations, it would be safe enough 10000 iterations. > > FYI: http://security.stackexchange.com/questions/3959/recommended-of-iterations-… > > OK. I've committed it without any changes, thanks for the patch. > > > It is desirable to be able to change the operator, but slapasswd does > > not read slapd.conf so I was stuck. > > I'm planning to change slappasswd that accept iteration count in the future. > > Thank you. > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Open Source Solution Technology Corporation HAMANO Tsukasa <hamano(a)osstech.co.jp> fingerprint = 2285 2111 6D34 3816 3C2E A5B9 16BE D101 6069 BE55

1 0

Re: (ITS#7978) OpenLDAP 2.4 fails to build with LibreSSL
by hyc＠symas.com 05 Nov '14

05 Nov '14

Spil Oss wrote: > Hi Howard, > > Thanks for the pointer. --enable-lmpasswd was indeed enabled in the > FreeBSD port. Notifying maintainer of port to switch it off and > provided a patch for the port. > Hope the patch I created for OpenLDAP is usable after all! Deprecated > code in a function that should not be used, would it not be better to > remove it completely? (or is that violating the RFCs?) Very likely we should remove it. Will queue that up for 2.5. 2.4 is end-of-life and feature-frozen so nothing will be added or removed from it. > Kind regards, > > Bernard. > > On Wed, Nov 5, 2014 at 5:48 PM, Howard Chu <hyc(a)symas.com> wrote: >> spil.oss(a)gmail.com wrote: >>> >>> Full_Name: Bernard Spil >>> Version: 2.4.40 >>> OS: FreeBSD 10.1-RC2 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (185.9.255.20) >>> >>> >>> When compiling OpenLDAP against the LibreSSL OpenSSL fork, compilation >>> fails >>> because deprecated types and functions are used. These types and functions >>> have >>> been marked deprecated by OpenSSL since 2002 and moved from des.h to >>> des_old.h. >>> LibreSSL removed these deprecated types and functions in April 2014 see >>> >>> https://github.com/libressl-portable/openbsd/commit/e0d211052a6946b9f8af112… >>> >>>> From the make output: >> >> >> It appears you're compiling with the old LANMAN hash support. Nobody should >> be using LANMAN any more, it's trivially insecure. I'm inclined to ignore >> this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7978) OpenLDAP 2.4 fails to build with LibreSSL
by spil.oss＠gmail.com 05 Nov '14

05 Nov '14

Hi Howard, Thanks for the pointer. --enable-lmpasswd was indeed enabled in the FreeBSD port. Notifying maintainer of port to switch it off and provided a patch for the port. Hope the patch I created for OpenLDAP is usable after all! Deprecated code in a function that should not be used, would it not be better to remove it completely? (or is that violating the RFCs?) Kind regards, Bernard. On Wed, Nov 5, 2014 at 5:48 PM, Howard Chu <hyc(a)symas.com> wrote: > spil.oss(a)gmail.com wrote: >> >> Full_Name: Bernard Spil >> Version: 2.4.40 >> OS: FreeBSD 10.1-RC2 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (185.9.255.20) >> >> >> When compiling OpenLDAP against the LibreSSL OpenSSL fork, compilation >> fails >> because deprecated types and functions are used. These types and functions >> have >> been marked deprecated by OpenSSL since 2002 and moved from des.h to >> des_old.h. >> LibreSSL removed these deprecated types and functions in April 2014 see >> >> https://github.com/libressl-portable/openbsd/commit/e0d211052a6946b9f8af112… >> >>> From the make output: > > > It appears you're compiling with the old LANMAN hash support. Nobody should > be using LANMAN any more, it's trivially insecure. I'm inclined to ignore > this ITS. >> >> >> --- passwd.o --- >> passwd.c:41:9: error: unknown type name 'des_cblock'; did you mean >> 'DES_cblock'? >> typedef des_cblock des_key; >> ^~~~~~~~~~ >> DES_cblock >> /usr/local/include/openssl/des.h:73:23: note: 'DES_cblock' declared here >> typedef unsigned char DES_cblock[8]; >> ^ >> passwd.c:42:9: erro3A3A unknown type name 'des_cblock'; did you mean >> 'DES_cblock'? >> typedef des_cblock des_data_block; >> ^~~~~~~~~~ >> DES_cblock >> /usr/local/include/openssl/des.h:73:23: note: 'DES_cblock' declared here >> typedef unsigned char DES_cblock[8]; >> ^ >> passwd.c:43:9: error: unknown type name 'des_key_schedule'; did you mean >> 'DES_key_schedule'? >> typedef des_key_schedule des_context; >> ^~~~~~~~~~~~~~~~ >> DES_key_schedule >> /usr/local/include/openssl/des.h:87:7: note: 'DESeyey_schedule' declared >> here >> } DES_key_schedule; >> ^ >> passwd.c:670:5: warning: implicit declaration of function >> 'des_set_odd_parity' >> is invalid in C99 [-Wimplicit-function-declaration] >> des_set_odd_parity( key ); >> ^ >> passwd.c:867:2: warningA imimplicit declaration of function >> 'des_set_key_unchecked' is invalid in C99 >> [-Wimplicit-function-declaration] >> des_set_key_unchecked( &key, schedule ); >> ^ >> passwd.c:868:2: warning: implicit declaration of function >> 'des_ecb_encrypt' is >> invalid in C99 [-Wimplicit-function-declaration] >> des_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT >> ); >> ^ >> 3 warnings and 3 errors generated. >> *** [passwd.o] Error code 1 >> >> make[4]: stopped in >> /usr/ports/net/openldap24-server/work/openldap-2.4.40/libraries/liblutil >> 1 error >> >> make[4]: stopped in >> /usr/ports/net/openldap24-server/work/openldap-2.4.40/libraries/liblutil >> *** [all-common] Error code 2 >> >> make[3]: stopped in >> /usr/ports/net/openldap24-server/work/openldap-2.4.40/librars%s >> 1 error >> >> make[3]: stopped in >> /usr/ports/net/openldap24-server/work/openldap-2.4.40/libraries >> *** [all-common] Error code 2 >> >> make[2]: stopped in /usr/ports/net/openldap24-server/work/openldap-2.4.40 >> 1 error >> >> make[2]: stopped in /u%2/ports/net/openldap24-server/work/openldap-2.4.40 >> ===> Compilation failed unexpectedly. >> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure >> to >> the maintainer. >> *** Error code 1 >> >> Stop. >> >> >> > > > -- > -- 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#7978) OpenLDAP 2.4 fails to build with LibreSSL
by bernard＠bachfreund.nl 05 Nov '14

05 Nov '14

--=_6538b474f9e6aa431d332f9d976b1b83 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Patch to upgrade to the current DES_* types and functions, at least compiles with this. On 2014-11-05 17:48, Howard Chu wrote: > spil.oss(a)gmail.com wrote: >> Full_Name: Bernard Spil >> Version: 2.4.40 >> OS: FreeBSD 10.1-RC2 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (185.9.255.20) >> >> >> When compiling OpenLDAP against the LibreSSL OpenSSL fork, compilation >> fails >> because deprecated types and functions are used. These types and >> functions have >> been marked deprecated by OpenSSL since 2002 and moved from des.h to >> des_old.h. >> LibreSSL removed these deprecated types and functions in April 2014 >> see >> https://github.com/libressl-portable/openbsd/commit/e0d211052a6946b9f8af112… >> >>> From the make output: > > It appears you're compiling with the old LANMAN hash support. Nobody > should be using LANMAN any more, it's trivially insecure. I'm inclined > to ignore this ITS. >> >> --- passwd.o --- >> passwd.c:41:9: error: unknown type name 'des_cblock'; did you mean >> 'DES_cblock'? >> typedef des_cblock des_key; >> ^~~~~~~~~~ >> DES_cblock >> /usr/local/include/openssl/des.h:73:23: note: 'DES_cblock' declared >> here >> typedef unsigned char DES_cblock[8]; >> ^ >> passwd.c:42:9: erro3A3A unknown type name 'des_cblock'; did you mean >> 'DES_cblock'? >> typedef des_cblock des_data_block; >> ^~~~~~~~~~ >> DES_cblock >> /usr/local/include/openssl/des.h:73:23: note: 'DES_cblock' declared >> here >> typedef unsigned char DES_cblock[8]; >> ^ >> passwd.c:43:9: error: unknown type name 'des_key_schedule'; did you >> mean >> 'DES_key_schedule'? >> typedef des_key_schedule des_context; >> ^~~~~~~~~~~~~~~~ >> DES_key_schedule >> /usr/local/include/openssl/des.h:87:7: note: 'DESeyey_schedule' >> declared here >> } DES_key_schedule; >> ^ >> passwd.c:670:5: warning: implicit declaration of function >> 'des_set_odd_parity' >> is invalid in C99 [-Wimplicit-function-declaration] >> des_set_odd_parity( key ); >> ^ >> passwd.c:867:2: warningA imimplicit declaration of function >> 'des_set_key_unchecked' is invalid in C99 >> [-Wimplicit-function-declaration] >> des_set_key_unchecked( &key, schedule ); >> ^ >> passwd.c:868:2: warning: implicit declaration of function >> 'des_ecb_encrypt' is >> invalid in C99 [-Wimplicit-function-declaration] >> des_ecb_encrypt( &StdText, &PasswordHash1, schedule , >> DES_ENCRYPT ); >> ^ >> 3 warnings and 3 errors generated. >> *** [passwd.o] Error code 1 >> >> make[4]: stopped in >> /usr/ports/net/openldap24-server/work/openldap-2.4.40/libraries/liblutil >> 1 error >> >> make[4]: stopped in >> /usr/ports/net/openldap24-server/work/openldap-2.4.40/libraries/liblutil >> *** [all-common] Error code 2 >> >> make[3]: stopped in >> /usr/ports/net/openldap24-server/work/openldap-2.4.40/librars%s >> 1 error >> >> make[3]: stopped in >> /usr/ports/net/openldap24-server/work/openldap-2.4.40/libraries >> *** [all-common] Error code 2 >> >> make[2]: stopped in >> /usr/ports/net/openldap24-server/work/openldap-2.4.40 >> 1 error >> >> make[2]: stopped in >> /u%2/ports/net/openldap24-server/work/openldap-2.4.40 >> ===> Compilation failed unexpectedly. >> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the >> failure to >> the maintainer. >> *** Error code 1 >> >> Stop. >> >> >> --=_6538b474f9e6aa431d332f9d976b1b83 Content-Transfer-Encoding: base64 Content-Type: text/x-diff; name=patch-libraries_liblutil_passwd.c Content-Disposition: attachment; filename=patch-libraries_liblutil_passwd.c; size=5977 LS0tIGxpYnJhcmllcy9saWJsdXRpbC9wYXNzd2QuYy5vcmlnCTIwMTQtMDktMTkgMDM6NDg6NDku MDAwMDAwMDAwICswMjAwCisrKyBsaWJyYXJpZXMvbGlibHV0aWwvcGFzc3dkLmMJMjAxNC0xMS0w NSAxOTo1NzoxMC44MDc1NTUwMjUgKzAxMDAKQEAgLTM4LDExICszOCwxMSBAQAogIwlpbmNsdWRl IDxvcGVuc3NsL2Rlcy5oPgogCiAKLXR5cGVkZWYgZGVzX2NibG9jayBkZXNfa2V5OwotdHlwZWRl ZiBkZXNfY2Jsb2NrIGRlc19kYXRhX2Jsb2NrOwotdHlwZWRlZiBkZXNfa2V5X3NjaGVkdWxlIGRl c19jb250ZXh0OwotI2RlZmluZSBkZXNfZmFpbGVkKGVuY3J5cHRlZCkgMAotI2RlZmluZSBkZXNf ZmluaXNoKGtleSwgc2NoZWR1bGUpIAordHlwZWRlZiBERVNfY2Jsb2NrIERFU19rZXk7Cit0eXBl ZGVmIERFU19jYmxvY2sgREVTX2RhdGFfYmxvY2s7Cit0eXBlZGVmIERFU19rZXlfc2NoZWR1bGUg REVTX2NvbnRleHQ7CisjZGVmaW5lIERFU19mYWlsZWQoZW5jcnlwdGVkKSAwCisjZGVmaW5lIERF U19maW5pc2goa2V5LCBzY2hlZHVsZSkgCiAKICNlbGlmIGRlZmluZWQoSEFWRV9NT1pOU1MpCiAv KgpAQCAtNTMsOSArNTMsOSBAQAogKi8KICNkZWZpbmUgUFJPVFlQRVNfSCAxCiAjCWluY2x1ZGUg PG5zcy9wazExcHViLmg+Ci10eXBlZGVmIFBLMTFTeW1LZXkgKmRlc19rZXk7Ci10eXBlZGVmIHVu c2lnbmVkIGNoYXIgZGVzX2RhdGFfYmxvY2tbOF07Ci10eXBlZGVmIFBLMTFDb250ZXh0ICpkZXNf Y29udGV4dFsxXTsKK3R5cGVkZWYgUEsxMVN5bUtleSAqREVTX2tleTsKK3R5cGVkZWYgdW5zaWdu ZWQgY2hhciBERVNfZGF0YV9ibG9ja1s4XTsKK3R5cGVkZWYgUEsxMUNvbnRleHQgKkRFU19jb250 ZXh0WzFdOwogI2RlZmluZSBERVNfRU5DUllQVCBDS0FfRU5DUllQVAogCiAjZW5kaWYKQEAgLTY2 NCwxMCArNjY0LDEwIEBACiAgKiBhYnN0cmFjdCBhd2F5IHNldHRpbmcgdGhlIHBhcml0eS4KICAq Lwogc3RhdGljIHZvaWQKLWRlc19zZXRfa2V5X2FuZF9wYXJpdHkoIGRlc19rZXkgKmtleSwgdW5z aWduZWQgY2hhciAqa2V5RGF0YSkKK0RFU19zZXRfa2V5X2FuZF9wYXJpdHkoIERFU19rZXkgKmtl eSwgdW5zaWduZWQgY2hhciAqa2V5RGF0YSkKIHsKICAgICBtZW1jcHkoa2V5LCBrZXlEYXRhLCA4 KTsKLSAgICBkZXNfc2V0X29kZF9wYXJpdHkoIGtleSApOworICAgIERFU19zZXRfb2RkX3Bhcml0 eSgga2V5ICk7CiB9CiAKIApAQCAtNjc3LDcgKzY3Nyw3IEBACiAgKiBpbXBsZW1lbnQgTW96TlNT IHdyYXBwZXJzIGZvciB0aGUgb3BlblNTTCBjYWxscyAKICAqLwogc3RhdGljIHZvaWQKLWRlc19z ZXRfa2V5X2FuZF9wYXJpdHkoIGRlc19rZXkgKmtleSwgdW5zaWduZWQgY2hhciAqa2V5RGF0YSkK K0RFU19zZXRfa2V5X2FuZF9wYXJpdHkoIERFU19rZXkgKmtleSwgdW5zaWduZWQgY2hhciAqa2V5 RGF0YSkKIHsKICAgICBTRUNJdGVtIGtleURhdGFJdGVtOwogICAgIFBLMTFTbG90SW5mbyAqc2xv dDsKQEAgLTY5OSw3ICs2OTksNyBAQAogfQogCiBzdGF0aWMgdm9pZAotZGVzX3NldF9rZXlfdW5j aGVja2VkKCBkZXNfa2V5ICprZXksIGRlc19jb250ZXh0IGN0eHQgKQorREVTX3NldF9rZXlfdW5j aGVja2VkKCBERVNfa2V5ICprZXksIERFU19jb250ZXh0IGN0eHQgKQogewogICAgIGN0eHRbMF0g PSBOVUxMOwogCkBAIC03MTIsMzcgKzcxMiwzNyBAQAogfQogCiBzdGF0aWMgdm9pZAotZGVzX2Vj Yl9lbmNyeXB0KCBkZXNfZGF0YV9ibG9jayAqcGxhaW4sIGRlc19kYXRhX2Jsb2NrICplbmNyeXB0 ZWQsIAotCQkJZGVzX2NvbnRleHQgY3R4dCwgaW50IG9wKQorREVTX2VjYl9lbmNyeXB0KCBERVNf ZGF0YV9ibG9jayAqcGxhaW4sIERFU19kYXRhX2Jsb2NrICplbmNyeXB0ZWQsIAorCQkJREVTX2Nv bnRleHQgY3R4dCwgaW50IG9wKQogewogICAgIFNFQ1N0YXR1cyBydjsKICAgICBpbnQgc2l6ZTsK IAogICAgIGlmIChjdHh0WzBdID09IE5VTEwpIHsKIAkvKiBuZWVkIHRvIGZhaWwgaGVyZS4uLiAg Ki8KLQltZW1zZXQoZW5jcnlwdGVkLCAwLCBzaXplb2YoZGVzX2RhdGFfYmxvY2spKTsKKwltZW1z ZXQoZW5jcnlwdGVkLCAwLCBzaXplb2YoREVTX2RhdGFfYmxvY2spKTsKIAlyZXR1cm47CiAgICAg fQogICAgIHJ2ID0gUEsxMV9DaXBoZXJPcChjdHh0WzBdLCAodW5zaWduZWQgY2hhciAqKSZlbmNy eXB0ZWRbMF0sIAotCQkJJnNpemUsIHNpemVvZihkZXNfZGF0YV9ibG9jayksCi0JCQkodW5zaWdu ZWQgY2hhciAqKSZwbGFpblswXSwgc2l6ZW9mKGRlc19kYXRhX2Jsb2NrKSk7CisJCQkmc2l6ZSwg c2l6ZW9mKERFU19kYXRhX2Jsb2NrKSwKKwkJCSh1bnNpZ25lZCBjaGFyICopJnBsYWluWzBdLCBz aXplb2YoREVTX2RhdGFfYmxvY2spKTsKICAgICBpZiAocnYgIT0gU0VDU3VjY2VzcykgewogCS8q IHNpZ25hbCBmYWlsdXJlICovCi0JbWVtc2V0KGVuY3J5cHRlZCwgMCwgc2l6ZW9mKGRlc19kYXRh X2Jsb2NrKSk7CisJbWVtc2V0KGVuY3J5cHRlZCwgMCwgc2l6ZW9mKERFU19kYXRhX2Jsb2NrKSk7 CiAJcmV0dXJuOwogICAgIH0KICAgICByZXR1cm47CiB9CiAKIHN0YXRpYyBpbnQKLWRlc19mYWls ZWQoZGVzX2RhdGFfYmxvY2sgKmVuY3J5cHRlZCkKK0RFU19mYWlsZWQoREVTX2RhdGFfYmxvY2sg KmVuY3J5cHRlZCkKIHsKLSAgIHN0YXRpYyBjb25zdCBkZXNfZGF0YV9ibG9jayB6ZXJvID0geyAw IH07CisgICBzdGF0aWMgY29uc3QgREVTX2RhdGFfYmxvY2sgemVybyA9IHsgMCB9OwogICAgcmV0 dXJuIG1lbWNtcChlbmNyeXB0ZWQsIHplcm8sIHNpemVvZih6ZXJvKSkgPT0gMDsKIH0KIAogc3Rh dGljIHZvaWQKLWRlc19maW5pc2goZGVzX2tleSAqa2V5LCBkZXNfY29udGV4dCBjdHh0KQorREVT X2ZpbmlzaChERVNfa2V5ICprZXksIERFU19jb250ZXh0IGN0eHQpCiB7CiAgICAgIGlmICgqa2V5 KSB7CiAJUEsxMV9GcmVlU3ltS2V5KCprZXkpOwpAQCAtODE3LDcgKzgxNyw3IEBACiAKIHN0YXRp YyB2b2lkIGxtUGFzc3dkX3RvX2tleSgKIAljb25zdCBjaGFyICpsbVBhc3N3ZCwKLQlkZXNfa2V5 ICprZXkpCisJREVTX2tleSAqa2V5KQogewogCWNvbnN0IHVuc2lnbmVkIGNoYXIgKmxwdyA9IChj b25zdCB1bnNpZ25lZCBjaGFyICopIGxtUGFzc3dkOwogCXVuc2lnbmVkIGNoYXIga1s4XTsKQEAg LTgzMiw3ICs4MzIsNyBAQAogCWtbNl0gPSAoKGxwd1s1XSAmIDB4M0YpIDw8IDIpIHwgKGxwd1s2 XSA+PiA2KTsKIAlrWzddID0gKChscHdbNl0gJiAweDdGKSA8PCAxKTsKIAkJCi0JZGVzX3NldF9r ZXlfYW5kX3Bhcml0eSgga2V5LCBrICk7CisJREVTX3NldF9rZXlfYW5kX3Bhcml0eSgga2V5LCBr ICk7CiB9CQogCiBzdGF0aWMgaW50IGNoa19sYW5tYW4oCkBAIC04NDMsMTAgKzg0MywxMCBAQAog ewogCWJlcl9sZW5fdCBpOwogCWNoYXIgVWNhc2VQYXNzd29yZFsxNV07Ci0JZGVzX2tleSBrZXk7 Ci0JZGVzX2NvbnRleHQgc2NoZWR1bGU7Ci0JZGVzX2RhdGFfYmxvY2sgU3RkVGV4dCA9ICJLR1Mh QCMkJSI7Ci0JZGVzX2RhdGFfYmxvY2sgUGFzc3dvcmRIYXNoMSwgUGFzc3dvcmRIYXNoMjsKKwlE RVNfa2V5IGtleTsKKwlERVNfY29udGV4dCBzY2hlZHVsZTsKKwlERVNfZGF0YV9ibG9jayBTdGRU ZXh0ID0gIktHUyFAIyQlIjsKKwlERVNfZGF0YV9ibG9jayBQYXNzd29yZEhhc2gxLCBQYXNzd29y ZEhhc2gyOwogCWNoYXIgUGFzc3dvcmRIYXNoWzMzXSwgc3RvcmVkUGFzc3dvcmRIYXNoWzMzXTsK IAkKIAlmb3IoIGk9MDsgaTxjcmVkLT5idl9sZW47IGkrKykgewpAQCAtODY0LDIxICs4NjQsMjEg QEAKIAlsZGFwX3B2dF9zdHIydXBwZXIoIFVjYXNlUGFzc3dvcmQgKTsKIAkKIAlsbVBhc3N3ZF90 b19rZXkoIFVjYXNlUGFzc3dvcmQsICZrZXkgKTsKLQlkZXNfc2V0X2tleV91bmNoZWNrZWQoICZr ZXksIHNjaGVkdWxlICk7Ci0JZGVzX2VjYl9lbmNyeXB0KCAmU3RkVGV4dCwgJlBhc3N3b3JkSGFz aDEsIHNjaGVkdWxlICwgREVTX0VOQ1JZUFQgKTsKKwlERVNfc2V0X2tleV91bmNoZWNrZWQoICZr ZXksICZzY2hlZHVsZSApOworCURFU19lY2JfZW5jcnlwdCggJlN0ZFRleHQsICZQYXNzd29yZEhh c2gxLCAmc2NoZWR1bGUgLCBERVNfRU5DUllQVCApOwogCi0JaWYgKGRlc19mYWlsZWQoJlBhc3N3 b3JkSGFzaDEpKSB7CisJaWYgKERFU19mYWlsZWQoJlBhc3N3b3JkSGFzaDEpKSB7CiAJICAgIHJl dHVybiBMVVRJTF9QQVNTV0RfRVJSOwogCX0KIAkKIAlsbVBhc3N3ZF90b19rZXkoICZVY2FzZVBh c3N3b3JkWzddLCAma2V5ICk7Ci0JZGVzX3NldF9rZXlfdW5jaGVja2VkKCAma2V5LCBzY2hlZHVs ZSApOwotCWRlc19lY2JfZW5jcnlwdCggJlN0ZFRleHQsICZQYXNzd29yZEhhc2gyLCBzY2hlZHVs ZSAsIERFU19FTkNSWVBUICk7Ci0JaWYgKGRlc19mYWlsZWQoJlBhc3N3b3JkSGFzaDIpKSB7CisJ REVTX3NldF9rZXlfdW5jaGVja2VkKCAma2V5LCAmc2NoZWR1bGUgKTsKKwlERVNfZWNiX2VuY3J5 cHQoICZTdGRUZXh0LCAmUGFzc3dvcmRIYXNoMiwgJnNjaGVkdWxlICwgREVTX0VOQ1JZUFQgKTsK KwlpZiAoREVTX2ZhaWxlZCgmUGFzc3dvcmRIYXNoMikpIHsKIAkgICAgcmV0dXJuIExVVElMX1BB U1NXRF9FUlI7CiAJfQogCi0JZGVzX2ZpbmlzaCggJmtleSwgc2NoZWR1bGUgKTsKKwlERVNfZmlu aXNoKCAma2V5LCBzY2hlZHVsZSApOwogCQogCXNwcmludGYoIFBhc3N3b3JkSGFzaCwgIiUwMngl MDJ4JTAyeCUwMnglMDJ4JTAyeCUwMnglMDJ4JTAyeCUwMnglMDJ4JTAyeCUwMnglMDJ4JTAyeCUw MngiLCAKIAkJUGFzc3dvcmRIYXNoMVswXSxQYXNzd29yZEhhc2gxWzFdLFBhc3N3b3JkSGFzaDFb Ml0sUGFzc3dvcmRIYXNoMVszXSwKQEAgLTExMzksMTAgKzExMzksMTAgQEAKIAogCWJlcl9sZW5f dCBpOwogCWNoYXIgVWNhc2VQYXNzd29yZFsxNV07Ci0JZGVzX2tleSBrZXk7Ci0JZGVzX2NvbnRl eHQgc2NoZWR1bGU7Ci0JZGVzX2RhdGFfYmxvY2sgU3RkVGV4dCA9ICJLR1MhQCMkJSI7Ci0JZGVz X2RhdGFfYmxvY2sgUGFzc3dvcmRIYXNoMSwgUGFzc3dvcmRIYXNoMjsKKwlERVNfa2V5IGtleTsK KwlERVNfY29udGV4dCBzY2hlZHVsZTsKKwlERVNfZGF0YV9ibG9jayBTdGRUZXh0ID0gIktHUyFA IyQlIjsKKwlERVNfZGF0YV9ibG9jayBQYXNzd29yZEhhc2gxLCBQYXNzd29yZEhhc2gyOwogCWNo YXIgUGFzc3dvcmRIYXNoWzMzXTsKIAkKIAlmb3IoIGk9MDsgaTxwYXNzd2QtPmJ2X2xlbjsgaSsr KSB7CkBAIC0xMTYwLDEyICsxMTYwLDEyIEBACiAJbGRhcF9wdnRfc3RyMnVwcGVyKCBVY2FzZVBh c3N3b3JkICk7CiAJCiAJbG1QYXNzd2RfdG9fa2V5KCBVY2FzZVBhc3N3b3JkLCAma2V5ICk7Ci0J ZGVzX3NldF9rZXlfdW5jaGVja2VkKCAma2V5LCBzY2hlZHVsZSApOwotCWRlc19lY2JfZW5jcnlw dCggJlN0ZFRleHQsICZQYXNzd29yZEhhc2gxLCBzY2hlZHVsZSAsIERFU19FTkNSWVBUICk7CisJ REVTX3NldF9rZXlfdW5jaGVja2VkKCAma2V5LCAmc2NoZWR1bGUgKTsKKwlERVNfZWNiX2VuY3J5 cHQoICZTdGRUZXh0LCAmUGFzc3dvcmRIYXNoMSwgJnNjaGVkdWxlICwgREVTX0VOQ1JZUFQgKTsK IAkKIAlsbVBhc3N3ZF90b19rZXkoICZVY2FzZVBhc3N3b3JkWzddLCAma2V5ICk7Ci0JZGVzX3Nl dF9rZXlfdW5jaGVja2VkKCAma2V5LCBzY2hlZHVsZSApOwotCWRlc19lY2JfZW5jcnlwdCggJlN0 ZFRleHQsICZQYXNzd29yZEhhc2gyLCBzY2hlZHVsZSAsIERFU19FTkNSWVBUICk7CisJREVTX3Nl dF9rZXlfdW5jaGVja2VkKCAma2V5LCAmc2NoZWR1bGUgKTsKKwlERVNfZWNiX2VuY3J5cHQoICZT dGRUZXh0LCAmUGFzc3dvcmRIYXNoMiwgJnNjaGVkdWxlICwgREVTX0VOQ1JZUFQgKTsKIAkKIAlz cHJpbnRmKCBQYXNzd29yZEhhc2gsICIlMDJ4JTAyeCUwMnglMDJ4JTAyeCUwMnglMDJ4JTAyeCUw MnglMDJ4JTAyeCUwMnglMDJ4JTAyeCUwMnglMDJ4IiwgCiAJCVBhc3N3b3JkSGFzaDFbMF0sUGFz c3dvcmRIYXNoMVsxXSxQYXNzd29yZEhhc2gxWzJdLFBhc3N3b3JkSGFzaDFbM10sCg== --=_6538b474f9e6aa431d332f9d976b1b83--

1 0

Re: (ITS#7978) OpenLDAP 2.4 fails to build with LibreSSL
by hyc＠symas.com 05 Nov '14

05 Nov '14

spil.oss(a)gmail.com wrote: > Full_Name: Bernard Spil > Version: 2.4.40 > OS: FreeBSD 10.1-RC2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (185.9.255.20) > > > When compiling OpenLDAP against the LibreSSL OpenSSL fork, compilation fails > because deprecated types and functions are used. These types and functions have > been marked deprecated by OpenSSL since 2002 and moved from des.h to des_old.h. > LibreSSL removed these deprecated types and functions in April 2014 see > https://github.com/libressl-portable/openbsd/commit/e0d211052a6946b9f8af112… > >>From the make output: It appears you're compiling with the old LANMAN hash support. Nobody should be using LANMAN any more, it's trivially insecure. I'm inclined to ignore this ITS. > > --- passwd.o --- > passwd.c:41:9: error: unknown type name 'des_cblock'; did you mean > 'DES_cblock'? > typedef des_cblock des_key; > ^~~~~~~~~~ > DES_cblock > /usr/local/include/openssl/des.h:73:23: note: 'DES_cblock' declared here > typedef unsigned char DES_cblock[8]; > ^ > passwd.c:42:9: erro3A3A unknown type name 'des_cblock'; did you mean > 'DES_cblock'? > typedef des_cblock des_data_block; > ^~~~~~~~~~ > DES_cblock > /usr/local/include/openssl/des.h:73:23: note: 'DES_cblock' declared here > typedef unsigned char DES_cblock[8]; > ^ > passwd.c:43:9: error: unknown type name 'des_key_schedule'; did you mean > 'DES_key_schedule'? > typedef des_key_schedule des_context; > ^~~~~~~~~~~~~~~~ > DES_key_schedule > /usr/local/include/openssl/des.h:87:7: note: 'DESeyey_schedule' declared here > } DES_key_schedule; > ^ > passwd.c:670:5: warning: implicit declaration of function 'des_set_odd_parity' > is invalid in C99 [-Wimplicit-function-declaration] > des_set_odd_parity( key ); > ^ > passwd.c:867:2: warningA imimplicit declaration of function > 'des_set_key_unchecked' is invalid in C99 [-Wimplicit-function-declaration] > des_set_key_unchecked( &key, schedule ); > ^ > passwd.c:868:2: warning: implicit declaration of function 'des_ecb_encrypt' is > invalid in C99 [-Wimplicit-function-declaration] > des_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT ); > ^ > 3 warnings and 3 errors generated. > *** [passwd.o] Error code 1 > > make[4]: stopped in /usr/ports/net/openldap24-server/work/openldap-2.4.40/libraries/liblutil > 1 error > > make[4]: stopped in /usr/ports/net/openldap24-server/work/openldap-2.4.40/libraries/liblutil > *** [all-common] Error code 2 > > make[3]: stopped in /usr/ports/net/openldap24-server/work/openldap-2.4.40/librars%s > 1 error > > make[3]: stopped in /usr/ports/net/openldap24-server/work/openldap-2.4.40/libraries > *** [all-common] Error code 2 > > make[2]: stopped in /usr/ports/net/openldap24-server/work/openldap-2.4.40 > 1 error > > make[2]: stopped in /u%2/ports/net/openldap24-server/work/openldap-2.4.40 > ===> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > the maintainer. > *** Error code 1 > > Stop. > > > -- -- 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#7978) OpenLDAP 2.4 fails to build with LibreSSL
by spil.oss＠gmail.com 05 Nov '14

05 Nov '14

Full_Name: Bernard Spil Version: 2.4.40 OS: FreeBSD 10.1-RC2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (185.9.255.20) When compiling OpenLDAP against the LibreSSL OpenSSL fork, compilation fails because deprecated types and functions are used. These types and functions have been marked deprecated by OpenSSL since 2002 and moved from des.h to des_old.h. LibreSSL removed these deprecated types and functions in April 2014 see https://github.com/libressl-portable/openbsd/commit/e0d211052a6946b9f8af112… >From the make output: --- passwd.o --- passwd.c:41:9: error: unknown type name 'des_cblock'; did you mean 'DES_cblock'? typedef des_cblock des_key; ^~~~~~~~~~ DES_cblock /usr/local/include/openssl/des.h:73:23: note: 'DES_cblock' declared here typedef unsigned char DES_cblock[8]; ^ passwd.c:42:9: erro3A3A unknown type name 'des_cblock'; did you mean 'DES_cblock'? typedef des_cblock des_data_block; ^~~~~~~~~~ DES_cblock /usr/local/include/openssl/des.h:73:23: note: 'DES_cblock' declared here typedef unsigned char DES_cblock[8]; ^ passwd.c:43:9: error: unknown type name 'des_key_schedule'; did you mean 'DES_key_schedule'? typedef des_key_schedule des_context; ^~~~~~~~~~~~~~~~ DES_key_schedule /usr/local/include/openssl/des.h:87:7: note: 'DESeyey_schedule' declared here } DES_key_schedule; ^ passwd.c:670:5: warning: implicit declaration of function 'des_set_odd_parity' is invalid in C99 [-Wimplicit-function-declaration] des_set_odd_parity( key ); ^ passwd.c:867:2: warningA imimplicit declaration of function 'des_set_key_unchecked' is invalid in C99 [-Wimplicit-function-declaration] des_set_key_unchecked( &key, schedule ); ^ passwd.c:868:2: warning: implicit declaration of function 'des_ecb_encrypt' is invalid in C99 [-Wimplicit-function-declaration] des_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT ); ^ 3 warnings and 3 errors generated. *** [passwd.o] Error code 1 make[4]: stopped in /usr/ports/net/openldap24-server/work/openldap-2.4.40/libraries/liblutil 1 error make[4]: stopped in /usr/ports/net/openldap24-server/work/openldap-2.4.40/libraries/liblutil *** [all-common] Error code 2 make[3]: stopped in /usr/ports/net/openldap24-server/work/openldap-2.4.40/librars%s 1 error make[3]: stopped in /usr/ports/net/openldap24-server/work/openldap-2.4.40/libraries *** [all-common] Error code 2 make[2]: stopped in /usr/ports/net/openldap24-server/work/openldap-2.4.40 1 error make[2]: stopped in /u%2/ports/net/openldap24-server/work/openldap-2.4.40 ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop.

1 0

Re: (ITS#7977) Supported PBKDF2-SHA256 and PBKDF2-SHA512
by hyc＠symas.com 05 Nov '14

05 Nov '14

Tsukasa HAMANO wrote: > Hi, Howard > > At Wed, 05 Nov 2014 09:32:43 +0000, > Howard Chu wrote: >> >> Any particular reason you've decreased the iterations from 60000 to 10000? >> > > It was too slow when stretching 60000 on powerless server. > My tiny VM needed over 1sec if iterate 60000 by PBKDF2-SHA512. > RFC recommends more than 1000 iterations, it would be safe enough 10000 iterations. > FYI: http://security.stackexchange.com/questions/3959/recommended-of-iterations-… OK. I've committed it without any changes, thanks for the patch. > It is desirable to be able to change the operator, but slapasswd does > not read slapd.conf so I was stuck. > I'm planning to change slappasswd that accept iteration count in the future. > Thank you. > -- -- 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#7977) Supported PBKDF2-SHA256 and PBKDF2-SHA512
by hamano＠osstech.co.jp 05 Nov '14

05 Nov '14

Hi, Howard At Wed, 05 Nov 2014 09:32:43 +0000, Howard Chu wrote: > > Any particular reason you've decreased the iterations from 60000 to 10000? > It was too slow when stretching 60000 on powerless server. My tiny VM needed over 1sec if iterate 60000 by PBKDF2-SHA512. RFC recommends more than 1000 iterations, it would be safe enough 10000 iterations. FYI: http://security.stackexchange.com/questions/3959/recommended-of-iterations-… It is desirable to be able to change the operator, but slapasswd does not read slapd.conf so I was stuck. I'm planning to change slappasswd that accept iteration count in the future. Thank you. -- Open Source Solution Technology Corporation HAMANO Tsukasa <hamano(a)osstech.co.jp> fingerprint = 2285 2111 6D34 3816 3C2E A5B9 16BE D101 6069 BE55

1 0

Re: (ITS#7977) Supported PBKDF2-SHA256 and PBKDF2-SHA512
by hyc＠symas.com 05 Nov '14

05 Nov '14

hamano(a)osstech.co.jp wrote: > Full_Name: HAMANO Tsukasa > Version: git master > OS: GNU/Linux > URL: https://www.osstech.co.jp/download/hamano/openldap-pbkdf2_sha2.patch > Submission from: (NULL) (240b:10:2640:bf0:426c:8fff:fe50:23a8) > > > I've supported new schemes PBKDF2-SHA256 and PBKDF2-SHA512. > Thank you. Any particular reason you've decreased the iterations from 60000 to 10000? > > -- > 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 HAMANO Tsukasa <hamano(a)osstech.co.jp>. I > have not assigned rights and/or interest in this work to any party. > > Copyright 2014 HAMANO Tsukasa <hamano(a)osstech.co.jp> > Redistribution and use in source and binary forms, with or without > modification, e e permitted only as authorized by the OpenLDAP Public > License. > > -- -- 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#7977) Supported PBKDF2-SHA256 and PBKDF2-SHA512
by hamano＠osstech.co.jp 05 Nov '14

05 Nov '14

Full_Name: HAMANO Tsukasa Version: git master OS: GNU/Linux URL: https://www.osstech.co.jp/download/hamano/openldap-pbkdf2_sha2.patch Submission from: (NULL) (240b:10:2640:bf0:426c:8fff:fe50:23a8) I've supported new schemes PBKDF2-SHA256 and PBKDF2-SHA512. Thank you. -- 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 HAMANO Tsukasa <hamano(a)osstech.co.jp>. I have not assigned rights and/or interest in this work to any party. Copyright 2014 HAMANO Tsukasa <hamano(a)osstech.co.jp> Redistribution and use in source and binary forms, with or without modification, e e permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#7976) Bug in syncrepl.c short-circuits overlay stack cleanup
by hyc＠symas.com 31 Oct '14

31 Oct '14

mwarren(a)symas.com wrote: > Full_Name: Mark Warren > Version: 2.4.32 > OS: RHEL > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (72.35.133.119) > > > > via Howard: > > "The bug is syncrepl.c lines 2036-2038. Returning LDAP_SUCCESS here > short-circuits the overlay stack and *doesn't* call the cleanup handlers." > > Note: The line numbers are skewed as we're working with an older version. On further analysis, it appears the patch is not needed in current code. It seems the problem (an incoming mod whose entryCSN matches the existing entryCSN of the target entry) was already avoided by the patch for ITS#7427, which was released in 2.4.34. Definitely unable to reproduce the issue in 2.4.40. -- -- 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#7976) Bug in syncrepl.c short-circuits overlay stack cleanup
by mwarren＠symas.com 30 Oct '14

30 Oct '14

Full_Name: Mark Warren Version: 2.4.32 OS: RHEL URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.35.133.119) via Howard: "The bug is syncrepl.c lines 2036-2038. Returning LDAP_SUCCESS here short-circuits the overlay stack and *doesn't* call the cleanup handlers." Note: The line numbers are skewed as we're working with an older version. Best Regards, Mark

1 0

Re: (ITS#7975) MDB search scope one and filter returns search base
by hyc＠symas.com 29 Oct '14

29 Oct '14

requate(a)univention.de wrote: > Full_Name: Arvid Requate > Version: 2.4.40 > OS: Debian / UCS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.198.197.8) > > > With an mdb backend the command > > ldapsearch -xLLL -b dc=ar40i1,dc=qa -s one objectClass=domain dn > > returns the base DN. With a bdb backend it doesn't. > > The crucial point seems to be the filter in this case, which matches the base > object only, and none of it's children. If I change the filter to > objectclass=top (or leave it away) then only the children are returned, just > like the behaviour of the bdb backend. Fixed now 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

(ITS#7975) MDB search scope one and filter returns search base
by requate＠univention.de 29 Oct '14

29 Oct '14

Full_Name: Arvid Requate Version: 2.4.40 OS: Debian / UCS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.198.197.8) With an mdb backend the command ldapsearch -xLLL -b dc=ar40i1,dc=qa -s one objectClass=domain dn returns the base DN. With a bdb backend it doesn't. The crucial point seems to be the filter in this case, which matches the base object only, and none of it's children. If I change the filter to objectclass=top (or leave it away) then only the children are returned, just like the behaviour of the bdb backend.

1 0

Re: (ITS#7974) LDBM's "laggard reader" flaw still present, in continue of ITS#7904
by leo＠yuriev.ru 23 Oct '14

23 Oct '14

I assume ITS#7830 is the same issue.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs