openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#8216) Windows 'make test' failures
by h.b.furuseth＠usit.uio.no 25 Oct '15

25 Oct '15

On 25/10/15 09:57, hyc(a)symas.com wrote: >> test043-delta-syncrepl: lmdb always fails, hdb/bdb sometimes > > Attribute ordering, the replicated data is correct. Won't fix this. Sounds like you can just replace "$LDIFFILTER -s bdb=a,hdb=a" with "$LDIFFILTER -s a" or add ",mdb=a".

1 0

Re: (ITS#8204) rfc2782 shuffle implementation doesn't treat equal-weight records equally
by hyc＠symas.com 25 Oct '15

25 Oct '15

Sergio.Gelato(a)astro.su.se wrote: > Full_Name: Sergio Gelato > Version: 2.4.40 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.225.123.9) > > > As currently implemented (since ITS#7027, > 5de85b922aaa5bfa6eb53db6000adf01ebdb0736) the algorithm to shuffle DNS SRV > records of a given priority according to their weights is flawed: if all records > have the same weight, the implementation is biased towards the first record and > against the last. In the most extreme case of two records of weight 1, the > current implementation will never swap them (whereas one would have hoped for a > swap 50% of the time). The problem can be cured by changing (r <= 0) to (r < 0). > (The wording of the RFC may have contributed to this error; I suspect it was > written with real random deviates in mind, not integer ones. In any event, the > principle that records of equal weight should have the same probability of being > picked trumps the RFC since the latter only says what algorithm SHOULD be > used.) > > I've written and tested a patch for this and found it to solve the above > problem. My patch also addresses another (operationally minor, which is why I'm > not reporting it separately) issue in the same piece of code: what if at least > two, but not all, of the records of a given priority have weight zero? One > should be prepared to switch to a Fisher-Yates shuffle if "total" becomes zero > during the iteration. > > (Yet another potential issue is overflow of "total" on platforms where > INT_MAX==32767 if the sum of the weights exceeds that value. Consider declaring > it uint32_t or u_long.) I see no patch nor URL. -- -- 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#8194) Service slapd falldown in a search with client ldapsearch
by hyc＠symas.com 25 Oct '15

25 Oct '15

richard.larrieu-manan(a)cgi.com wrote: > Ok. > > Here is the command line to do the research with the client ldapsearch : > /opt/openldap/bin/ldapsearch -xLLL -h ldapp02 -p 389 -D cn=3Dadmin,ou=3Dsys= > tem,dc=3Dent,dc=3Dfr -b ou=3Dsupp,ou=3Dpersonnes,ou=3DCRRA,dc=3Dent,dc=3Dfr= > -w jungle dn | wc -l > > After 1 or 2 search the slapd server goes. I believe this was fixed as ITS#8203 in 2.4.42. Please try that and followup again, thanks. > > Thx. > > -----Message d'origine----- > De=A0: Michael Str=F6der [mailto:michael@stroeder.com]=20 > Envoy=E9=A0: vendredi 10 juillet 2015 12:35 > =C0=A0: LARRIEU-MANAN, Richard; openldap-its(a)OpenLDAP.org > Objet=A0: Re: (ITS#8194) Service slapd falldown in a search with client lda= > psearch > > Maybe I missed something but I can't which search requests are causing this= > . > > Could you please also add some information about your ldapsearch commands? > > Ciao, Michael. > > > > -- -- 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#8191) mdb_txn_commit(empty txn) does not sync
by hyc＠symas.com 25 Oct '15

25 Oct '15

h.b.furuseth(a)usit.uio.no wrote: > On 07/07/15 21:44, h.b.furuseth(a)usit.uio.no wrote: >> My feeling is that this is a quirk the user should not need to >> know about, and it's cleaner to sy r rather than to document it. > > ...cleaner to sync rather than... The doc should say that committing an empty txn is a no-op. If you want to do a sync without writing data, use mdb_env_sync() yourself. -- -- 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#8205)
by hyc＠symas.com 25 Oct '15

25 Oct '15

peter(a)adpm.de wrote: > Hi, > > I extended the patch series with a manual page for pbkdf2 > * https://github.com/marschap/openldap/commit/f63202e8aa68e3391f52d2481f649ca… > contrib/passwd/pbkdf2: add man page, install it too Please use format-patch to submit patches, thanks. -- -- 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#8211) ssf does not reflect actual security of connection
by hyc＠symas.com 25 Oct '15

25 Oct '15

hkario(a)redhat.com wrote: > Full_Name: Hubert Kario > Version: all > OS: Linux > URL: > Submission from: (NULL) (213.175.37.10) > > > Section "14.2.1. Security Strength Factors"[1] states "A SSF greater than one > (>1) roughly correlates to the effective encryption key length.". This is not > the case more often than not. > > Problem is that ssf as it is calculated now doesn't take into consideration > all the cryptographic primitives in use. > > In other words, a connection that uses a 512 bit RSA certificates and > negotiates TLS_RSA_WITH_AES_128_CBC_SHA (AES256-SHA) certainly does not > provide security equivalent to "modern strong ciphers"[2][3] and should be > awarded "256". > > Similarly a connection that uses 512 bit DH parameters and negotiates > TLS_DHE_RSA_WITH_AES_256_CBC_SHA (DHE-RSA-AES256-SHA) does not provide > security that should be awarded "256"[5]. > > In fact, recommending use of high key sizes[2] will cause the connection to > use _less_ secure CBC ciphersuites[5] with clients that support AEAD > ciphersuites with AES-128 only (like Thunderbird and Firefox do). > > Section 8.4.9[2] also calls RC4 a "modern strong cipher", most cryptographers > disagree[6]. > > > So I think either: > 1). ssf needs to be redefined to consider any value higher that "2" to be > equal, and requiring the server administrators to enable only > ciphersuites they consider secure, or > 2). the whole code that calculates ssf needs to be updated to take into > account many more things: > * use of AEAD > * use of Encrypt-then-MAC > * the protocol version used (both because TLS1.0 specific attacks[7] as > wewell as the use of SHA1+MD5 for signatures which limits the connection > security to 80 bits[8] (optimistically) if client certificates are in > use in TLS < 1.2) > * encryption algorithm on session tickets > * current state of attacks on a given ciphersuite > * the size of ECDHE curve, FFDHE prime or server certificate key size, > depending on ciphersuite negotiated > * the signature algorithm used in Certificate Verify message > * the key size of client certificate > * the signature on the client certificate and key sizes in CA > certificates > * the HMAC used > * key size of the symmetric cipher > * (probably other things I didn't think about) > > 1 - http://www.openldap.org/doc/admin24/security.html > 2 - http://w.w.openldap.org/doc/admin24/access-control.html section 8.4.9 > 3 - https://freakattack.com/ > 4 - https://weakdh.org/ > 5 - http://www.isg.rhul.ac.uk/tls/Lucky13.html > 6 - https://tools.ietf.org/html/rfc7465 > 7 - https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack > 8 - https://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf Patch welcome. Either a doc patch describing your option (1) or a code patch for your (2). Note that SSF generally comes to us from SASL, so a code patch most likely needs to be submitted to the Cyrus-SASL Project, not us. Overall the definition of SSF has been in use in the industry for many years; it's not something we created or control. Changing the description or definition of it likely needs to also happen elsewhere. -- -- 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#8114) [WIP] WiredTiger Backend for OpenLDAP
by hyc＠symas.com 25 Oct '15

25 Oct '15

HAMANO Tsukasa wrote: > Thanks for merging. > Also I've added LDAP MODIFY. > Please merge the patches: > https://www.osstech.co.jp/download/hamano/openldap/0007-suppress-warn-messa… > https://www.osstech.co.jp/download/hamano/openldap/0008-LDAP-MODIFY-handlin… Added in 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

Re: (ITS#8215) Slapmodify delete support and documentation
by hyc＠symas.com 25 Oct '15

25 Oct '15

ondra(a)mistotebe.net wrote: > Full_Name: Ond&#345;ej Kuzn.k > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150811-slapmodify-delete-su… > Submission from: (NULL) (62.84.155.99) > > > It is only possible to delete entries in a back-ldif database. This patchset > implements the equivalent functionality in the other core databases, enables the > same in back-config and adds a slapmodify manpage. With that in place, > test007-slapmodify is switched to fail on errors now. ModRDN stays unimplemented > at this point. > > An outstanding issue is that valgrind complains about a memory leak in bdb on > entry delete, which I have not been able to pinpoint nor fix. Thanks. Committed to master. We'll keep this ITS open until the leak is fixed. > > The above patch is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the above patches were > developed by Ondřej Kuzník <ondra(a)mistotebe.net>. I have not assigned > rights and/or interest in this work to any party. > > I, Ondřej Kuzník, hereby place the above modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, > these modifications may be freely used and/or redistributed for any > purpose with or without attribution and/or other notice. > > -- -- 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#8216) Windows 'make test' failures
by hyc＠symas.com 25 Oct '15

25 Oct '15

mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.4.40 > OS: Windows 7/64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.43.206.100) > > > Many 'make test' test fail, for a variety of reasons, with LMDB and BDB/HDB > backends. > > OpenLDAP 2.4.40 > Berkeley DB 4.8.30 > > > Environment: > MSYS from MinGW/MSYS 2013072300 > Win-Builds MinGW 32- and 64-bit toolchain > > The following tests fail: > test0-c-concurrency: problems reported by slapd-tester > test039-glue-ldap-concurrency: seems to fail for the same reasons as test008 libtool incompatibility; it leaves shell scripts for the actual tester programs in the progs directory, with the real executables under progs/.libs. Windows' spawn can't execute shell scripts. Solution is to manually copy the real executables from .libs before running the test. Simple workaround. Won't fix this. > test043-delta-syncrepl: lmdb always fails, hdb/bdb sometimes Attribute ordering, the replicated data is correct. Won't fix this. > test049-sync-config: config parsing problems > test050-syncrepl-multimaster: config parsing problems Fixed as ITS#8273 > test056-monitor: incorrect monitor output Fixed as ITS#8280 > test058-syncrepl-asymmetric: parsing problems > test059-slave-config: parsing problems > test061-syncreplication-initiation: parsing prlelems > test063-delta-multimaster: undetermined > test064-constraint: include file processing (parsing?) All ITS#8273. Closing this ITS. -- -- 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#8237) Crash with MDB_MAXKEYSIZE=1500
by hyc＠symas.com 25 Oct '15

25 Oct '15

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root(): > > The paste got munged. Test program at > <ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-150906.c>. Fixed. -- -- 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

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