openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

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 29 Oct '14

29 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 22 Oct '14

22 Oct '14

I assume ITS#7830 is the same issue.

1 0

Re: (ITS#7830) MDB Size grown a lot during massive updates and concurrent read access
by leo＠yuriev.ru 22 Oct '14

22 Oct '14

Seems to will be fixed by ITS#7974.

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