openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

Re: (ITS#8267) contributing a new overlay unicodepw
by hyc＠symas.com 25 Oct '15

25 Oct '15

Ingo Voss wrote: > > > Am 17.10.2015 um 20:58 schrieb Howard Chu: >> ingo.voss(a)gmail.com wrote: >>> Full_Name: Ingo Voss >>> Version: >>> OS: >>> URL: ftp://ftp.openldap.org/incoming/contrib-slapd-modules-unicodepw.tar >>> Submission from: (NULL) (78.53.86.212) >>> >>> >>> Hello, >>> >>> I wrote a small overlay, that restricts all LDAP modification requests, so >>> that >>> only password changes for MS unicodePwd are possible. >>> All other LDAP requests will not be observed. >>> If someone needs a read-only proxy (in a e.g. dmz) for an MS Active Directory, >>> but password changes must be possible, then unicodepw is the right overlay. >>> For more informations, a manual page is included. >> >> If you want a read-only proxy, shouldn't this overlay also intercept and >> deny all Add/Delete/ModDN requests? >> > > Yes, you are right! But such overlay (denyop) exist already and it is working > well. > The manual page for unicodepw refers to denyop and describes the complete > configuration in detail. OK. This code is full of C++ comments. OpenLDAP uses C comments only. This code is full of SPACEs for indentation. OpenLDAP uses TAB characters for indentation, with 4-column tab stops. Your debug messages are using STATS debug level. STATS is reserved for LDAP operation/parameter logging only and is the default level. Code should be silent at the default level unless major errors have occurred. This code cannot be accepted in its current form. -- -- 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#8281) Syncrepl refresh failure when slapd is restarted midstream
by hyc＠symas.com 23 Oct '15

23 Oct '15

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Michael Ströder wrote: >>> hyc(a)symas.com wrote: >>>> Michael Ströder wrote: >>>>> hyc(a)symas.com wrote: >>>>>> Generating a new contextCSN at startup is of questionable worth. We discussed >>>>>> this a bit 'way back in 2004 >>>>>> http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perhaps we >>>>>> should just not do it; >>>>> >>>>> +1 >>>>> >>>>>> if a single-master provider starts up empty and a >>>>>> consumer tries to talk to it and both have an empty cookie, the provider >>>>>> should just respond "you're up to date". >>>>> >>>>> Why not return an error to the consumer? >>>> >>>> Typically if a consumer receives an error it will disconnect and retry later. >>>> There's not much point making the consumer reconnect - which may be costly for >>>> a TCP session. If it's a refreshAndPersist consumer, it just needs to hang on >>>> and wait for some real data to arrive. >>> >>> Is the cost really that high compared to the rest of the initialization? >> >> I meant "TLS" there. > > As I'm solely using TLS secured LDAP connection *everywhere* I also implied > TLS. Still I assume opening the syncrepl connection a few times again is > nothing compared to the majority LDAP clients opening connections for every > single LDAP simple bind request. So if it simplifies error handling which > likely results in more robustness, I'd strongly prefer that. As it turns out, it greatly simplified things to handle this condition as you suggest. Fixed now in git 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

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