openldap-bugs January 2015

openldap-bugs@openldap.org

22 participants
114 discussions

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

Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by leo＠yuriev.ru 13 Jan '15

13 Jan '15

2015-01-13 13:50 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>: > On 01/12/2015 07:15 PM, leo(a)yuriev.ru wrote: >> >> Unfortunately IMDB programmed without accounting possibility of memory >> reordering and cache incoherency (as a proof - the 'volatile' was >> missed before ITS#7969). >> So, currently seems LMDB is durable only on x86 and may be on MIPS. > > > I gather "volatile" in thread code can be read as "warning: dubious > code" or at best "please access this sooner rather than later". > > 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, `volatile` don't needed, when a locking (e.g. mutex) is used for access to any variables that shared between threads. But LMDB don't uses locking primitives for interaction between writers and readers. LMDB properties declared as: - readers don't block writers and writers don't block readers; - read transactions are extremely cheap, and can be performed using no mallocs or any other _blocking_ calls; THEREFORE 'volatile' and memory-ordering ISSUES MUST BE HANDLED VERY CAREFULLY AND ANXIOUSLY. > 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". > The best fix is likely a format change which reduces the need for sync > primitives, for LDMBv2. Checksum the MDB_meta, and/or replace the > variable part with a single word which refers to the meta. > Don't know if we can get rid of unportable sync code though. Yes it is possible, but requires C++, see http://en.cppreference.com/w/cpp/atomic/memory_order By using just C, include C99 - not possible, see http://stackoverflow.com/questions/27301371/memory-order-consistency-model-… > Leaving the rest to Howard, I'm too busy just now to do more than blow > hot air:-) Ok ;) I created gist for public review, please share it. https://gist.github.com/leo-yuriev/ba186a6bf5cf3a27bae7 Leonid.

1 0

Re: (ITS#8018) a lot of warnings building with -Wall
by h.b.furuseth＠usit.uio.no 13 Jan '15

13 Jan '15

On 01/12/2015 05:22 PM, leo(a)yuriev.ru wrote: > 2015-01-12 17:19 GMT+03:00 Hallvard Breien Furuseth < > h.b.furuseth(a)usit.uio.no>: >> The Debug() change is going to give merge conflicts all over >> the place when your <https://github.com/ReOpen/ReOpenLDAP> and >> OpenLDAP pull updates from each other. >> >> https://github.com/ReOpen/ReOpenLDAP should not be used for merge, but > only for cherry-picking. Oops, right. "cherry-picking conflicts":-) > It has stripped history and merged with OpenLDAP/mdb.master, because > mdb.RE/0.9 don't includes a few critical fixes (ITS 7969,7970,7971) for our > case. > I think that is the reason for patch conflicts. > Patchset got RE25 should remain among my sent emails. Presumably I can send > it for you again, if you are interested. No, I was talking about maintaining the two projects in the future. Presumably you'll want to copy fixes from OpenLDAP, and we'll want fixes from you. Any such change next to a Debug() statement will not apply cleanly, and must be hand-edited. >> How about defining Debug1(), Debug2(), etc for 1,2... arguments? >> That's still annoying, but it keeps the code C90-compatible and >> keeps -Wformat quiet. There's already similar code for Log<N>() >> in include/ldap_log.h, but it was never used much or even merged >> into RE24. (Because it got scheduled for RE25 which was going to >> start Real Soon Now, IIRC:-) > > IMHO the Log<N> recipe is onerously for support. > On other hand, nowadays all non-obsolete compilers support most of C99 > features. > Baseline features, such as "variadic macro", supported long ago (Microsoft > was the most conservative to 2012). > Maybe it is time to enable C99 in RE25? Dunno. People do use old compilers. OpenLDAP is conservative about portability. It requires C90 to build, but exports K&R1-compatible headers. Well, it tries. K&R1 compat was broken by OpenLDAP 2.0 (ITS#6171) and nobody who cares about K&R1 has bothered to fix it. When we do move towards C99, maybe we'll first test the waters by making Debug() use __VA_ARGS__ but not change the Debug() calls yet, so we'll only have a few lines to revert it it proves premature. We'll hear what Kurt says. -- Hallvard

1 0

Re: (ITS#8022) Backend Meta does not work with ssl-backends
by dirk.kastens＠uni-osnabrueck.de 13 Jan '15

13 Jan '15

Hi, > I've pushed fixes for both of these problems to git master and back-meta > works on ldaps:// for me now. Since I didn't reproduce your symptoms, I > have no idea if this will improve things for you or not. Please test and > follow up, thanks. Great! This perfectly works for me. I just compiled the latest git version. Now the meta directory works with ldaps. Thanks for your support. -- Dirk Kastens Universitaet Osnabrueck, Rechenzentrum (Computer Center) Albrechtstr. 28, 49069 Osnabrueck, Germany Tel.: +49-541-969-2347, FAX: -2470

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 01/12/2015 07:15 PM, leo(a)yuriev.ru wrote: > Unfortunately IMDB programmed without accounting possibility of memory > reordering and cache incoherency (as a proof - the 'volatile' was > missed before ITS#7969). > So, currently seems LMDB is durable only on x86 and may be on MIPS. I gather "volatile" in thread code can be read as "warning: dubious code" or at best "please access this sooner rather than later". 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. 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. The best fix is likely a format change which reduces the need for sync primitives, for LDMBv2. Checksum the MDB_meta, and/or replace the variable part with a single word which refers to the meta. Don't know if we can get rid of unportable sync code though. Leaving the rest to Howard, I'm too busy just now to do more than blow hot air:-) -- Hallvard

1 0

← Newer
1
...
4
5
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2015