openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org 14 Jan '15

14 Jan '15

Hi,=0A=0AI tried 2.4.39 under FreeBSD and still had the same issue.=0A=0A= I have also tried the packages for both CentOS 7 and Debian Wheezy, but u= nfortunately neither of them include the SHA2 overlay by default.=0A=0AFi= nally, I tried installing zimbra-core and zimbra-ldap under CentOS. When = I used this installation, it worked successfully.=0A=0AI ran slapd -V on = the zimbra installation, and it's 2.4.39. However, based on it still not = working on 2.4.39 on FreeBSD it appears to have narrowed it down to two r= easons:=0A- An issue with the packaging under FreeBSD=0A- The functionali= ty is specific to Zimbra=0A=0AThe next step in the process to narrow this= down is to do a manual compilation on CentOS, including the SHA2 overlay= . If this works, then it would confirm it to be a FreeBSD issue, and if i= t doesn't work that would strongly suggest that Zimbra has modified somet= hing.=0A=0AThanks for the assistance so far,=0A=0A-Jonathan=0A=0AJanuary = 13 2015 8:00 PM, "Quanah Gibson-Mount" <quanah(a)zimbra.com> wrote: =0A> --= On Tuesday, January 13, 2015 7:24 PM +0000 Jonathan Price=0A> <freebsd@jo= nathanprice.org> wrote:=0A> =0A>> I do apologise for the confusion, I'll = try to clarify below:=0A>> =0A>> Here is the command you ran successfully= :=0A>> /opt/zimbra/openldap/sbin/slappasswd -h=0A>> '{SSHA512}' -o module= -path=3D/opt/zimbra/openldap/sbin/openldap -o=0A>> module-load=3Dpw-sha2 = -s test=0A>> {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5= We5HNkXxFfy5=0A>> Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9=0A>> =0A>> Here is an= example of me running just a plain SHA512=0A>> slappasswd -h '{SHA512}' = -o module-path=3D/usr/local/libexec/openldap -o=0A>> module-load=3Dpw-sha= 2=0A>> {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvI= h/1nsUN=0A>> zLDBMxfqa2Ob1f1ACio/w=3D=3D=0A>> =0A>> And here is an exampl= e of me running a salted SHA512 (SSHA512)=0A>> slappasswd -h '{SSHA512}' = -o module-path=3D/usr/local/libexec/openldap -o=0A>> module-load=3Dpw-sha= 2 -s test=0A>> Password verification failed.=0A>> =0A>> I hope this helps= to clarify.=0A> =0A> Yes, thank you. So I'm using 2.4.39. There were som= e minor changes to=0A> slapd-sha2 in 2.4.40. I will see if I can reproduc= e the issue with current=0A> RE24.=0A> =0A> --Quanah=0A> =0A> --=0A> =0A>= Quanah Gibson-Mount=0A> Platform Architect=0A> Zimbra, Inc. =0A> _______= ________________________=0A> =0A> Zimbra :: the leader in open source mes= saging and collaboration

1 0

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

13 Jan '15

On 13/01/15 19:23, Hallvard Breien Furuseth wrote: > Yes, that didn't come out right. I don't mind inserting the > volatile, but I don't know that it helps either. As far as I > understand if it was broken without volatile, then it's still > broken with it - just hopefully less likely to break. And LMDB > couldn't be releaseed with your original unportable sync code > along with the volatile. Sorry, nevermind. Of course when the writer does sync well enough, volatile + the txn_renew loop will have to do for a sync primitive in the reader. I suppose this requires that sync in the writer thread will shake other threads as well, it won't be private to the writer. -- Hallvard

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by quanah＠zimbra.com 13 Jan '15

13 Jan '15

--On Tuesday, January 13, 2015 7:24 PM +0000 Jonathan Price <freebsd(a)jonathanprice.org> wrote: > I do apologise for the confusion, I'll try to clarify below: > > Here is the command you ran successfully: > /opt/zimbra/openldap/sbin/slappasswd -h > '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o > module-load=pw-sha2 -s test > {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5 > Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 > > Here is an example of me running just a plain SHA512 > slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o > module-load=pw-sha2 > {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUN > zLDBMxfqa2Ob1f1ACio/w== > > And here is an example of me running a salted SHA512 (SSHA512) > slappasswd -h '{SSHA512}' -o module-path=/usr/local/libexec/openldap -o > module-load=pw-sha2 -s test > Password verification failed. > > I hope this helps to clarify. Yes, thank you. So I'm using 2.4.39. There were some minor changes to slapd-sha2 in 2.4.40. I will see if I can reproduce the issue with current RE24. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org 13 Jan '15

13 Jan '15

I do apologise for the confusion, I'll try to clarify below: Here is the command you ran successfully: /opt/zimbra/openldap/sbin/slappasswd -h '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o module-load=pw-sha2 -s test {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5 Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 Here is an example of me running just a plain SHA512 slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUNzLDBMxfqa2Ob1f1ACio/w== And here is an example of me running a salted SHA512 (SSHA512) slappasswd -h '{SSHA512}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s test Password verification failed. I hope this helps to clarify. On 2015-01-13 19:14, Quanah Gibson-Mount wrote: > --On Tuesday, January 13, 2015 7:11 PM +0000 Jonathan Price > <freebsd(a)jonathanprice.org> wrote: > >> Hi, >> >> From the original email: >> However, if I replace {SHA512} with {SSHA512} it produces the following >> output: >> Password verification failed. > > You also were not clear *where* you did this replacement. It is > certainly not valid to do this replacement on the generated hash, as the > generated has was non-salted, and just adding another S in there will > not magically make it salted. It is valid to do this replacement in the > slappasswd line when generating a hash, as per my example, so that a > salted hash is generated. > > --Quanah > > >> It's interesting to see that it does work under certain conditions then. >> It appears that your OpenLDAP installation is part of a Zimbra >> installation. Does Zimbra make any modifications to OpenLDAP, or is it >> just built on top of it? >> >> Either way, I think I'm going to try it on Debian, just to rule out it >> being a FreeBSD issue, which it quite well could be at this point. >> >> On 2015-01-13 19:01, Quanah Gibson-Mount wrote: >>> --On Tuesday, January 13, 2015 6:52 PM +0000 freebsd(a)jonathanprice.org >>> wrote: >>> >>>> Full_Name: Jonathan Price >>>> Version: 2.4.40 >>>> OS: FreeBSD 10.1 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (80.47.105.54) >>>> >>>> >>>> I have compiled version 2.4.40 with the SHA2 module enabled. >>>> >>>> I then run the slappasswd with the following arguments: >>>> slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o >>>> module-load=pw-sha2 >>> >>> You requested a non salted hash -> SHA512 >>> >>> Did you try requesting a salted hash? -> SSHA512 >>> >>> Works fine for me, and I've been using it in production for quite some >>> time. >>> >>> [zimbra@zre-ldap003 ~]$ /opt/zimbra/openldap/sbin/slappasswd -h >>> '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o >>> module-load=pw-sha2 -s test >>> {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5 >>> Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 >>> >>> >>> >>> --Quanah >>> >>> -- >>> >>> Quanah Gibson-Mount >>> Platform Architect >>> Zimbra, Inc. >>> -------------------- >>> Zimbra :: the leader in open source messaging and collaboration > > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by quanah＠zimbra.com 13 Jan '15

13 Jan '15

--On Tuesday, January 13, 2015 7:11 PM +0000 Jonathan Price <freebsd(a)jonathanprice.org> wrote: > Hi, > > From the original email: > However, if I replace {SHA512} with {SSHA512} it produces the following > output: > Password verification failed. You also were not clear *where* you did this replacement. It is certainly not valid to do this replacement on the generated hash, as the generated has was non-salted, and just adding another S in there will not magically make it salted. It is valid to do this replacement in the slappasswd line when generating a hash, as per my example, so that a salted hash is generated. --Quanah > It's interesting to see that it does work under certain conditions then. > It appears that your OpenLDAP installation is part of a Zimbra > installation. Does Zimbra make any modifications to OpenLDAP, or is it > just built on top of it? > > Either way, I think I'm going to try it on Debian, just to rule out it > being a FreeBSD issue, which it quite well could be at this point. > > On 2015-01-13 19:01, Quanah Gibson-Mount wrote: >> --On Tuesday, January 13, 2015 6:52 PM +0000 freebsd(a)jonathanprice.org >> wrote: >> >>> Full_Name: Jonathan Price >>> Version: 2.4.40 >>> OS: FreeBSD 10.1 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (80.47.105.54) >>> >>> >>> I have compiled version 2.4.40 with the SHA2 module enabled. >>> >>> I then run the slappasswd with the following arguments: >>> slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o >>> module-load=pw-sha2 >> >> You requested a non salted hash -> SHA512 >> >> Did you try requesting a salted hash? -> SSHA512 >> >> Works fine for me, and I've been using it in production for quite some >> time. >> >> [zimbra@zre-ldap003 ~]$ /opt/zimbra/openldap/sbin/slappasswd -h >> '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o >> module-load=pw-sha2 -s test >> {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5 >> Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 >> >> >> >> --Quanah >> >> -- >> >> Quanah Gibson-Mount >> Platform Architect >> Zimbra, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by quanah＠zimbra.com 13 Jan '15

13 Jan '15

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org 13 Jan '15

13 Jan '15

Hi, From the original email: However, if I replace {SHA512} with {SSHA512} it produces the following output: Password verification failed. It's interesting to see that it does work under certain conditions then. It appears that your OpenLDAP installation is part of a Zimbra installation. Does Zimbra make any modifications to OpenLDAP, or is it just built on top of it? Either way, I think I'm going to try it on Debian, just to rule out it being a FreeBSD issue, which it quite well could be at this point. On 2015-01-13 19:01, Quanah Gibson-Mount wrote: > --On Tuesday, January 13, 2015 6:52 PM +0000 freebsd(a)jonathanprice.org > wrote: > >> Full_Name: Jonathan Price >> Version: 2.4.40 >> OS: FreeBSD 10.1 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.47.105.54) >> >> >> I have compiled version 2.4.40 with the SHA2 module enabled. >> >> I then run the slappasswd with the following arguments: >> slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o >> module-load=pw-sha2 > > You requested a non salted hash -> SHA512 > > Did you try requesting a salted hash? -> SSHA512 > > Works fine for me, and I've been using it in production for quite some > time. > > [zimbra@zre-ldap003 ~]$ /opt/zimbra/openldap/sbin/slappasswd -h > '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o > module-load=pw-sha2 -s test > {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 > > > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by quanah＠zimbra.com 13 Jan '15

13 Jan '15

--On Tuesday, January 13, 2015 6:52 PM +0000 freebsd(a)jonathanprice.org wrote: > Full_Name: Jonathan Price > Version: 2.4.40 > OS: FreeBSD 10.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.47.105.54) > > > I have compiled version 2.4.40 with the SHA2 module enabled. > > I then run the slappasswd with the following arguments: > slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o > module-load=pw-sha2 You requested a non salted hash -> SHA512 Did you try requesting a salted hash? -> SSHA512 Works fine for me, and I've been using it in production for quite some time. [zimbra@zre-ldap003 ~]$ /opt/zimbra/openldap/sbin/slappasswd -h '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o module-load=pw-sha2 -s test {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org 13 Jan '15

13 Jan '15

Full_Name: Jonathan Price Version: 2.4.40 OS: FreeBSD 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.47.105.54) I have compiled version 2.4.40 with the SHA2 module enabled. I then run the slappasswd with the following arguments: slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 This works successfully, and in this example I used the word "test" and it produced the following output: {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUNzLDBMxfqa2Ob1f1ACio/w== However, if I replace {SHA512} with {SSHA512} it produces the following output: Password verification failed. I have tested SHA256 SHA384 and SHA512. All three of these work fine. All three of SSHA256, SSHA384 and SSHA512 do not work however. It appears that there is an issue with slappasswd and salted SHA2 hashes. I have checked that 2.4.40 is new enough to have a version of the SHA2 overlay, and also checked the source to make sure it was definitely a new enough version, and can confirm that it is. Unfortunately, beyond this basic level of checking, I'm not a C programmer so I can't investigate the issue further myself.

1 0

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

13 Jan '15

On 13/01/15 17:54, leo(a)yuriev.ru wrote: > 2015-01-13 13:50 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>: >> comp.programming.threads's advise is that volatile is useless for thread >> sync: You need sync primitives, and then you don't need volatile since >> the compiler/hardware may not move the memory access past the primitive. > > Excuse me, but seems you are misunderstand comp.programming.threads in > case of blocking/locking multithreading and non-blocking > multithreading (aka lock-free/wait-free). Yes, that didn't come out right. I don't mind inserting the volatile, but I don't know that it helps either. As far as I understand if it was broken without volatile, then it's still broken with it - just hopefully less likely to break. And LMDB couldn't be releaseed with your original unportable sync code along with the volatile. > (...) >> Unless the primitive's spec says so, I guess. E.g. with an "asm" >> statement where the compiler does not know what the assembly code does >> and must be told not to mess with ordering. > > Please study GCC's manual about __asm __volalile (:::"memory"), this > is just a "full compiler fence". Thanks, looks good. Will read the rest later. -- Hallvard

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