openldap-devel March 2017

openldap-devel@openldap.org

8 participants
12 discussions

asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder 04 Nov '21

04 Nov '21

hyc(a)symas.com wrote in ITS#8240: > Our patch response was too hasty. There is no OpenLDAP bug here, the real > issue is production binaries being built with asserts enabled instead of > compiling with -DNDEBUG. That's an issue for packagers and distros to resolve. > Closing this ITS, not an OpenLDAP bug. Maybe I missed something. But this is the first time I've heard about -DNDEBUG being mandatory when compiling binary packages for production use. Does it have other effects? And what are general rules for assert statements in OpenLDAP code? In my own (Python) code assert statements are supposed to be only triggered if something goes wrong *internally* (type issues etc.). If somebody manages to trigger an assert statement with invalid input from "outside" I always consider this to be a serious bug revealing insufficient error handling even though e.g. web2ldap just logs the exception but won't crash. YMMV, but please clarify. I also wonder whether there are more mandatory rules for building packages and where I can find them. Please don't get me wrong: My inquiry is in good faith to avoid unnecessary ITS based on misunderstanding. Ciao, Michael.

1 1

Fwd: LMDB and text encoding
by Timur Kristóf 07 Jun '17

07 Jun '17

> I just had a look at how BDB handled this. As you can see they used a > TO_TSTRING macro to convert incoming pathnames from UTF8 to UTF16. > > https://gitorious.org/berkeleydb/berkeleydb/source/347d239a1e44ed4f773ae927… > > https://gitorious.org/berkeleydb/berkeleydb/source/347d239a1e44ed4f773ae927… > > (And a FROM_TSTRING for the reverse, as well.) (Mea culpa, I accidentally hit "reply" instead of "reply all". Sorry. Now reposting to the mailing list.) Since we only need to do this on Windows, we could use MultiByteToWideChar with CP_UTF8. (That's what TO_TSTRING does, too.) I do not think we would ever need to do any such conversion on UNIX. https://msdn.microsoft.com/en-us/library/windows/desktop/dd319072%28v=vs.85… I'm not sure if we can just copy-paste BDB's code. Probably not, that would lead to licensing issues, wouldn't it?

4 16

Re: openldap.git branch master updated. e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d
by Howard Chu 15 Mar '17

15 Mar '17

Hallvard Breien Furuseth wrote: > On 15. mars 2017 12:15, openldap-commit2devel(a)OpenLDAP.org wrote: >> commit e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d >> Author: Howard Chu <hyc(a)openldap.org> >> Date: Wed Mar 15 11:13:09 2017 +0000 >> >> Fixes for multiple threadpool queues >> >> Remove poolq_hash, it wasn't distributing work evenly to the queues. > > Not surprising when it was hashing the address instead of contents > of a local variable. Whatever that intended to achieve, it looks > to me like rand_r() would have done the same but better. It was hashing the bytes of arg. In the common case of the slapd_daemon_task submitting jobs to the pool, arg was the socket descriptor of an active connection, so this was always distributing those evenly. But in other cases where arg was a context pointer, the result was heavily skewed. > (Also the > hash was pointlessly slow in that it walked a byte at a time, it > could have hashed better with fewer operations.) for a 4 or 8 byte arg this was hardly important. > I guess I should have looked closer at that code earlier:-) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: openldap.git branch master updated. e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d
by Hallvard Breien Furuseth 15 Mar '17

15 Mar '17

On 15. mars 2017 12:15, openldap-commit2devel(a)OpenLDAP.org wrote: > commit e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d > Author: Howard Chu <hyc(a)openldap.org> > Date: Wed Mar 15 11:13:09 2017 +0000 > > Fixes for multiple threadpool queues > > Remove poolq_hash, it wasn't distributing work evenly to the queues. Not surprising when it was hashing the address instead of contents of a local variable. Whatever that intended to achieve, it looks to me like rand_r() would have done the same but better. (Also the hash was pointlessly slow in that it walked a byte at a time, it could have hashed better with fewer operations.) I guess I should have looked closer at that code earlier:-) -- Hallvard

1 0

Re: ldif API
by Quanah Gibson-Mount 13 Mar '17

13 Mar '17

--On Monday, March 13, 2017 7:46 PM +0000 Brett Sheffield <brett(a)gladserv.com> wrote: Hi Brett, > Which leads me to ask three questions: > > 1) Am I correct in thinking this will make it into the 2.5 release? Yes, it's already in the RE25 development branch. > 2) Is there a rough release date planned for 2.5? Not at this time. We had been planning on doing an initial alpha for 2.5 to get the ball rolling on sunsetting 2.4. I'd still like to get to that point, but we need to get the current 2.4 release stable first (Things like ITS#8444, ITS#8609, ITS#8589, ITS#8559, ITS#8545, ITS#8436, ITS#8528, ITS#8125, etc). There are also a couple of items that need fixing in master/RE25 before we do a 2.5 alpha as well. > 3) I've submitted my first patch to openldap[2], adding a new function > ldif_open_mem() which is useful when working with ldif data in memory. I > read through the contribution guidelines and I think I've made all the > necessary copyright statements etc., but please let me know if I've > missed anything. It would be great if this made it into 2.5 as well (tis Great, thanks! I can't say when it will be responded to as it'll need a code review, most likely from Howard, and I know he's currently heavily involved in a customer project for Symas. The simple fact is, the project needs more active participants, particularly knowledgable C programmers, so that things do not continually back up waiting on Howard for a response to even get somewhere on them. :/ --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

ldif API
by Brett Sheffield 13 Mar '17

13 Mar '17

Greetings all, I'm new to the list. I'm told I should be asking my questions here (thanks Gavin). One of my programs[1] uses the as yet un-released LDIF API (ldap_parse_ldif_record() and friends), which presently means installing from openldap master. This was originally pulled in to master back in April 2010, but unfortunately hasn't made it into a stable release yet, which makes using it rather painful for those of us that do. Which leads me to ask three questions: 1) Am I correct in thinking this will make it into the 2.5 release? 2) Is there a rough release date planned for 2.5? 3) I've submitted my first patch to openldap[2], adding a new function ldif_open_mem() which is useful when working with ldif data in memory. I read through the contribution guidelines and I think I've made all the necessary copyright statements etc., but please let me know if I've missed anything. It would be great if this made it into 2.5 as well (tis a small patch). Cheers, Brett [1] https://github.com/brettsheffield/libgladdb [2] http://www.OpenLDAP.org/its/index.cgi?findid=8603 -- __________________________________________________________ Application Hosting | Virtual Servers | Monitoring | Email Tel: 0131 510 0340 http://www.gladserv.com/

1 0

Argon2 Password Hashing
by Simon Levermann 08 Mar '17

08 Mar '17

Hello, as discussed in https://www.openldap.org/its/index.cgi/Incoming?id=8575;selectid=8575, I'm currently working on making my argon2 password hashing module also work with libsodium instead of just the argon2 reference implementation. In the progress, a few questions came up: 1) Libsodium doesn't expose all of the same parameters to argon2 that the original implementation exposes. In Libsodium, we can only configure the memory and CPU cost, while argon2 also allows configuring the salt length (fixed 16bytes in libsodium), the hash length (fixed 32bytes in libsodium), and the parallelism (fixed 1 thread in libsodium). So the question is: Do we want to expose these when using the argon2 backend, or do we not want to expose them at all, offering a more unified "API"? Personally, I think these parameters are sane and don't really need to be configurable (as opposed to the work factors, which SHOULD be configurable) 2) Libsodium exposes an API for random-number-generation. Should I use this API for generating the salt when using argon2, or should I always use the openldap-builtin lutil_entropy? 3) Regarding configurability: Is there a guide available that shows how to add configuration parameters to a module? In my current configuration, the memory and CPU cost factors are hardcoded into the module, but making these configurable for users is desirable, since they can potentially raise security based on the amount of Users vs amount of processing power they have. Best regards, Simon Levermann

2 4

Re: scrypt ASICs - litecoin N, r, p settings - Re: Revisiting the SHA1 default password hash
by Emily Backes 07 Mar '17

07 Mar '17

> Requiring 1GB for a password hash will preclude using it on small devices, > e.g. raspberry pi. > > Even 16MB is excessive. It's sounding like the newer and more complicated hashes have a lot of configurable features that may need site-local tuning. Should these be part of e.g. slapd.conf config or be settings embedded in the value format for later clarity, like {HASHNAME:attr=val,attr=val,attr=val}SnVzdCBhbiBleGFtcGxlLCBzaWxseQ== Considering the size of some of these newfangled hashes, attribute length doesn't look to be a relevant concern any longer. Realistically this would probably be a better way to express things like salt values in addition to the iteration counts and so on. If a structured value is what we really want there, BER might be more appropriate, possibly with a leading {EXTENDED-STRUCTURE} hash declaration. -- Emily Backes Symas Corporation ebackes(a)symas.com

3 3

Re: scrypt ASICs - litecoin N, r, p settings - Re: Revisiting the SHA1 default password hash
by Howard Chu 07 Mar '17

07 Mar '17

Lorenzo M. Catucci wrote: > Just to add some context to Howard Chu's message from Sat, 25 Feb 2017, > I'd like to point out that the scrypt settings chosen for litecoin PoW, > which I think are the ones commercial mining hardware are optimized for, are > some orders of magnitude different than the ones recommended for user > authentication, and are not, in my humble opinion, a sufficient reason to > exclude the scrypt construct from consideration: > > - https://litecoin.info/Scrypt > uses N = 1024, r = 1, p = 1 > which means using > 1024 * 1 * 1 * 128 = 128 KiBytes bytes of memory > and doing > 2 * (1024 * 1) = 2 Ki hashing rounds > > - the traditional default values for the parameters are > N = 16384, r = 8, p = 1 , which means using > 2^16 * 8 * 1 * 128 = 16 MiBytes of memory > and doing > 32Ki hashing rounds > > and these values can be customized (almost) at will to increase both the > computational effort and the memory footprint of the password hashing; e.g. > libsodium's crypto_pwhash_scryptsalsa208sha256 sets N = 2^20 in the > "{OPS,MEM}LIMIT_SENSITIVE" case, leading to a memory occupation of 1GiB and > an hashing rounds count of 2 * 2^20. Requiring 1GB for a password hash will preclude using it on small devices, e.g. raspberry pi. Even 16MB is excessive. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Argon2 Password Hashing
by Howard Chu 07 Mar '17

07 Mar '17

Simon Levermann wrote: > 2) Libsodium exposes an API for random-number-generation. Should I use > this API for generating the salt when using argon2, or should I always > use the openldap-builtin lutil_entropy? Salts are not sensitive data, they're always stored in the clear anyway. The only property they're required to have is to be unique among a given population of users/passwords. lutil_entropy is preferable just for uniformity, but it's not really critical. You could use anything, as long as you're not using something like this https://www.xkcd.com/221/ . -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel March 2017