openldap-bugs

openldap-bugs@openldap.org

1 participants
20996 discussions

Re: (ITS#4941) incorrect description of TLS_REQCERT setting
by hyc＠symas.com 03 Jul '07

03 Jul '07

Philip Guenther wrote: > On Mon, 30 Apr 2007, Howard Chu wrote: >> guenther+ldapdev(a)sendmail.com wrote: > ... >>> - 'allow' checks the identity of the server vs its cert (per RFC 4513, >>> section 3.1.3) and will terminate the connection if they don't match >>> - 'try' is the same as 'demand' and 'hard' >> Not quite. With both "allow" and "try" it's OK if the server provides no >> certificate. > > That's true of 'demand' and 'hard' as well. The only difference between > 'try' and 'demand' in the code is that the latter passes > SSL_CTX_set_verify() the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag, but that > flag has NO EFFECT on SSL clients. This is documented on the > SSL_CTX_set_verify() manpage and confirmed by grepping the openssl source > for it. > > If you don't believe me, I suggest you try configuring your server to > accept the ADH suites (don't forget to set TLSDHParamFile to /dev/null) > and give ldapsearch a whirl with > LDAPTLS_REQCERT=hard > LDAPTLS_CIPHER_SUITE=ADH-AES256-SHA > > in your environment. That's what I did. When this text was written, there was no support for anonymous cipher suites. So the meaning of the text is: assuming a cipher suite that actually uses certificates, the client would proceed even if the server didn't provide a cert. It's entirely possible that this circumstance has been overcome by other developments. Most likely this hasn't been a valid use case for quite a long time. But it has nothing to do with Diffie-Hellman key exchanges... -- -- Howard Chu Chief Architect, 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#5036) test034-translucent fails on HEAD
by hyc＠symas.com 03 Jul '07

03 Jul '07

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth.070703.tgz.1 >> Submission from: (NULL) (129.240.202.105) >> Submitted by: hallvard >> >> >> test034-translucent fails. Output: > >> Configuration: --disable-dynamic --enable-crypt --enable-lmpasswd >> --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers >> --disable-backends --enable-bdb --enable-ldap --enable-relay --enable-null >> --enable-meta --enable-overlays CC=gcc-4.2.0 'CPPFLAGS=-DLDAP_DEPRECATED >> -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' > > Strange. I got the same result with those options. But with this configuration, > the test works fine: > > --enable-modules --enable-backends=mod --enable-overlays=mod --enable-slapi > --disable-sql > > The test also fails with your options, but without any of the CPPFLAGS set. > Duh... In your test back-monitor is missing. Usually the monitor would be olcDatabase={1} in the config, so the bdb instance would be olcDatabase={2}, and that's the name that's coded into the script. -- -- Howard Chu Chief Architect, 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#5036) test034-translucent fails on HEAD
by hyc＠symas.com 03 Jul '07

03 Jul '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth.070703.tgz.1 > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > test034-translucent fails. Output: > Configuration: --disable-dynamic --enable-crypt --enable-lmpasswd > --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers > --disable-backends --enable-bdb --enable-ldap --enable-relay --enable-null > --enable-meta --enable-overlays CC=gcc-4.2.0 'CPPFLAGS=-DLDAP_DEPRECATED > -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' Strange. I got the same result with those options. But with this configuration, the test works fine: --enable-modules --enable-backends=mod --enable-overlays=mod --enable-slapi --disable-sql The test also fails with your options, but without any of the CPPFLAGS set. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5036) test034-translucent fails on HEAD
by h.b.furuseth＠usit.uio.no 03 Jul '07

03 Jul '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth.070703.tgz.1 Submission from: (NULL) (129.240.202.105) Submitted by: hallvard test034-translucent fails. Output: $ ./run test034 Cleaning up test run directory leftover from previous run. Running ./scripts/test034-translucent... running defines.sh == thr_debug: Leaked 1 mutexes. == == thr_debug: Leaked 1 mutexes. == Running slapadd to build remote slapd database... == thr_debug: Leaked 6 mutexes. == Starting remote slapd on TCP/IP port 9011... Starting local slapd on TCP/IP port 9012... Testing slapd Translucent Proxy operations... Testing search: no remote data defined... Populating remote database... Testing search: remote database via local slapd... Testing add: prohibited local record... Testing add: valid local record, no_glue... Testing modrdn: valid local record, no_glue... Dynamically configuring local slapd without translucent_no_glue... modifying entry "olcOverlay={0}translucent,olcDatabase={2}bdb,cn=config" ldap_modify: No such object (32) matched DN: cn=config ldapmodify of dynamic config failed (32) Enclosing logs from testrun directory. Configuration: --disable-dynamic --enable-crypt --enable-lmpasswd --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers --disable-backends --enable-bdb --enable-ldap --enable-relay --enable-null --enable-meta --enable-overlays CC=gcc-4.2.0 'CPPFLAGS=-DLDAP_DEPRECATED -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG'

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 03 Jul '07

03 Jul '07

Cut&paste errors... h.b.furuseth(a)usit.uio.no writes: > I forgot keys must be pointers. s/keys/thread-specific data/ > So ldap_pvt_thread_unique_id() would > malloc it if not already set, and fill in with the incremented pointers. s/incremented pointers/incremented counter/.

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 03 Jul '07

03 Jul '07

h.b.furuseth(a)usit.uio.no writes: > Oh, and make max_pending 0 or greater, since > negative numbers confuse pool_query(). I'll do that one, since it fixes a bug and removes no functionality. (And I forgot a few others, e.g. swapkey() function I mentioned earlier, but guess I'd prefer to stick to single-file changes for now.) >> OK, suppose we use a pthread thread-specific key here. What are you >> proposing for the unique value? > > An unsigned long counter, maintained by libldap_r. If the thread-local > variable is zero (thus uninitialized), increment the counter and grab > its value. I forgot keys must be pointers. So ldap_pvt_thread_unique_id() would malloc it if not already set, and fill in with the incremented pointers. For pool threads that'd not be necessary: The thread-local could hold the pointer to the thread context, and the thread could have unique ID (thread_context - thread_keys + 1). The "+1" in case others think thread ID 0 means no thread, like tpool thought recently. The comp.programming.threads question took off in an unexpected direction, so I'm not holding my breath about answers to DCE threads and the like. OS/390 threads - a quick google does seem to indicate that OS/400 threads (and thus presumably OS/390) resemble DCE threads. At least they have a pthread_getunique_np() function, and possibly "field1-3". -- Regards, Hallvard

1 0

Re: (ITS#5027) loglevel if none specified
by ando＠sys-net.it 03 Jul '07

03 Jul '07

steve(a)stevenwills.com wrote: > a great deal of logging is done. This seems inconsistent. Either the docs or the > code are incorrect. Which is right? The man page is incorrect. By default, loglevel is stats. Fixed in HEAD/re23. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5032) cannot build on x86_64, needs newer libtool
by bgmilne＠staff.telkomsa.net 02 Jul '07

02 Jul '07

--nextPart2297483.Rso0kROPCI Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday, 30 June 2007, h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23, HEAD > OS: RedHat Linux/x86_64 > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > libtool translates -ldb-4.3 to /usr/lib/libdb-4.3.so, which breaks. > "cc -ldb-4.3" uses /lib64/libdb-4.3.so. Only if the 32bit package is installed (which unfortunately happens by defa= ult=20 e.g. with 'yum install db4-devel' you get both i386 and x86_64). On RHEL5: # rpm -e db4-devel-4.3.29-9.fc6.i386 works around this. Regards, Buchan =2D-=20 Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592) http://en.wikipedia.org/wiki/List_of_Internet_slang_phrases --nextPart2297483.Rso0kROPCI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGiQdQrJK6UGDSBKcRAp3mAKDCZ+E3X5R85vVnxKGKwGmzU8elawCfRSfV dpfd0S1AdPcYJoQOt5UZbxc= =4+i/ -----END PGP SIGNATURE----- --nextPart2297483.Rso0kROPCI--

1 0

Re: (ITS#5032) cannot build on x86_64, needs newer libtool
by h.b.furuseth＠usit.uio.no 02 Jul '07

02 Jul '07

I just forgot to autoconf:-( It works if I use libtool-1.5.24 and run libtoolize --copy --force aclocal autoconf However I'm doing something wrong. With libtool 1.5.22, which OpenLDAP uses now, the build/ltmain.sh and build/config.* I generate don't match the existing ones. Nor aclocal.m4 when I run aclocal, but then I don't know which automake version to use. Is OpenLDAP using a patched libtool? One of the differences is that ltmain.sh contains VERSION=1.5.22-OpenLDAP, while I get VERSION=1.5.22. build/README is outdated, it says we use libtool 1.4.3. -- Regards, Hallvard

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 02 Jul '07

02 Jul '07

hyc(a)symas.com writes: >h.b.furuseth(a)usit.uio.no wrote: >> I wonder if we've been waiting for each other... Anyway, I've committed >> some pending fixes now that HEAD passes all tests for me. I've some >> more cleanup, but if we are close to a freeze I don't know if that means >> I should rush it in or wait until afterwards. > > Cleanup as in tidying the code, or as in fixing functionality? One cleanup (move thread start before queuing task in pool_submit(), one mini functionality: Make thread counts int instead of long, since pool_query() wants that. Oh, and make max_pending 0 or greater, since negative numbers confuse pool_query(). >> Another time when tls.c code loses information is if pointers are wider >> than long, which does happen. (Don't know how it is nowadays, but I >> remember plenty of postings about it some years ago.) > > Probably the OpenSSL API should have used a void * here. Too bad. Yup. I've seen mention it is coming in future version. > OK, suppose we use a pthread thread-specific key here. What are you > proposing for the unique value? An unsigned long counter, maintained by libldap_r. If the thread-local variable is zero (thus uninitialized), increment the counter and grab its value. >>>>> It's really >>>>> not hard. If we were to disallow increasing the number of threads at >>>>> runtime, we could simply allocate a block of thread stacks all at once, >>>>> which would then allow our thread IDs to be simple integers from 0-N. >> >> IIRC disallowing that would fix some other tpool problem too, but I >> don't remember what. > > I'm not really keen on that since I like having the ability to both increase > and decrease the setting dynamically. Me too, the only pro is it makes implementation simpler. >> Which led me to notice that the setstacksize call now _decreases_ the >> stack size on some hosts. I don't suppose that was intentional, so I >> guess it should be >> size_t cursize; >> if( pthread_attr_getstacksize( &attr, &cursize ) >> || cursize < LDAP_PVT_THREAD_STACK_SIZE ) >> pthread_attr_setstacksize( &attr, LDAP_PVT_THREAD_STACK_SIZE ); >> in thr_posix and I don't know what in other thr_* files. A RE24 change >> I guess, since reduces the max number of threads before slapd gets into >> trouble. > > I don't consider this a bug. If someone wants a larger thread stack > they can recompile to get it. Or perhaps we should make it a tunable > variable and add a config keyword for it. OK -- Regards, Hallvard

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