asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder
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 year, 6 months
Re: openldap.git branch master updated. e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d
by Howard Chu
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/
6 years, 2 months
Re: openldap.git branch master updated. e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d
by Hallvard Breien Furuseth
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
6 years, 2 months
Re: ldif API
by Quanah Gibson-Mount
--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>
6 years, 2 months
ldif API
by Brett Sheffield
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/
6 years, 2 months
Argon2 Password Hashing
by Simon Levermann
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
6 years, 2 months
Re: scrypt ASICs - litecoin N, r, p settings - Re: Revisiting the SHA1 default password hash
by Emily Backes
> 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
6 years, 2 months
Re: scrypt ASICs - litecoin N, r, p settings - Re: Revisiting the SHA1 default password hash
by Howard Chu
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/
6 years, 2 months
Re: Argon2 Password Hashing
by Howard Chu
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/
6 years, 2 months
