- openldap-bugs - openldap.org

Re: (ITS#7168) [PATCH] Fix count constraint when using multiple modifications
by hyc＠symas.com 07 Jun '12

07 Jun '12

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: 2.4.29 > OS: Fedora 16 > URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-coun… > Submission from: (NULL) (209.132.186.34) > > > Constraint overlay doesn't take into account multiple modifications when using > count. > > Example: If count for 'description' attribute is set e.g. to 2, the following > results in a constraint violation: > > dn: cn=usr2, dc=my-domain,dc=com > add: description > description: d1 > description: d2 > description: d3-viol > > However, this passes: > > dn: cn=usr2, dc=my-domain,dc=com > add: description > description: d1 > - > add: description > description: d2 > - > add: description > description: d3 > > This patch fixes the behavior in case multiple modifications are used. > > Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=742163 > > The patch is uploaded on fedorapeople.org: > http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-coun… > > I wasn't able to use ftp.openldap.org due to 'No space left' error. This code (and the original) don't seem to properly take deletes into account. It resets the ce counter to 0 on any delete op, but it should be decrementing based on the number of values provided. (And of course, it can only do that if the specified value is actually present in the attribute.) > The attached file is derived from OpenLDAP Software. All of the modifications > to > OpenLDAP Software represented in the following patch(es) were developed by Red > Hat. Red Hat has not assigned rights and/or interest in this work to any party. > I, Jan Synacek am authorized by Red Hat, my employer, to release this work > under > the following terms. > > Red Hat hereby place the following 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#7291) [PATCH] MozNSS: read pin from file file can cause infinite loop
by hyc＠symas.com 07 Jun '12

07 Jun '12

jvcelak(a)redhat.com wrote: >> might read initialized memory and consider it to be a password. In this > > sorry, typo: uninitialized Thanks for the patch, committed to 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#7289) Mozilla NSS: cipher suite selection by name may be ignored
by hyc＠symas.com 07 Jun '12

07 Jun '12

tim.strobell.ctr(a)nrl.navy.mil wrote: > Forgot to add that this bug is (was) masked by ITS#7285. Thanks for the patch, committed to 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#7292) Memory leak with MMR + delta syncrepl
by brandon.hume＠DAL.CA 06 Jun '12

06 Jun '12

On 06/ 6/12 12:57 PM, Quanah Gibson-Mount wrote: > > These may not be causing the issue you are seeing, but they should be > fixed and then the setup retested. Of particular concern to me is > item (a). I would make cn=monitor be olcDatabase {3}. Done, thanks for pointing out the problems. I think I introduced them accidentally while backend-hopping during testing, but I'll check my prod setup as well. I've made the changes and retested. The new node is still replicating, but after 50 cpu-minutes the process is at 10.2G and still going. I believe the leak is still present.

1 0

Re: (ITS#7291) [PATCH] MozNSS: read pin from file file can cause infinite loop
by jvcelak＠redhat.com 06 Jun '12

06 Jun '12

> might read initialized memory and consider it to be a password. In this sorry, typo: uninitialized

1 0

Re: (ITS#7286) Malformed search filter to back-ldap/slapo-rwm crashes slapd
by michael＠stroeder.com 06 Jun '12

06 Jun '12

masarati(a)aero.polimi.it wrote: > On 06/05/2012 12:48 PM, hyc(a)symas.com wrote: >> gahaverkamp(a)lbl.gov wrote: >>> --e89a8fb1fbfae973ef04c1b0bad6 >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> I thought I had, but I now see that I left off "full". >>> >>> (gdb) bt full >> >> We slso need to see the slapd config. > > Without carefully looking at it, it could be related to reinstalling the > original context because of the error. See ITS#6166. There's a similar issue ITS#6997 in which you also referenced ITS#6166. In case of ITS#6997 it used to work with OpenLDAP 2.4.23 but does not with 2.4.24+. Maybe Greg could check whether his setup would also work with 2.4.23. Ciao, Michael.

1 0

Re: (ITS#7292) Memory leak with MMR + delta syncrepl
by quanah＠zimbra.com 06 Jun '12

06 Jun '12

--On Wednesday, June 06, 2012 2:33 PM +0000 brandon.hume(a)dal.ca wrote: > Full_Name: Brandon Hume > Version: 2.4.31 > OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64 > URL: http://den.bofh.ca/~hume/ol-2.4.31_memleak.tar.gz > Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e) > > > OpenLDAP 2.4.31 compiled in 64-bit with BerkeleyDB 5.3.15 appears to > exhibit a memory leak while replicating the full database from another > node in MMR. There are definite errors in your cn=config configuration. a) You have multiple databases numbered "1": dn: olcDatabase={1}hdb,cn=config dn: olcDatabase={1}monitor,cn=config b) Syncprov overlay for accesslog: dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config Remove the checkpoint and sessionlog settings c) There should be no sessionlog on the primary DB with delta-syncrepl MMR: dn: olcOverlay={0}syncprov,olcDatabase={2}hdb,cn=config Remove olcSpSessionlog: 10000 These may not be causing the issue you are seeing, but they should be fixed and then the setup retested. Of particular concern to me is item (a). I would make cn=monitor be olcDatabase {3}. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7292) Memory leak with MMR + delta syncrepl
by brandon.hume＠dal.ca 06 Jun '12

06 Jun '12

Full_Name: Brandon Hume Version: 2.4.31 OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64 URL: http://den.bofh.ca/~hume/ol-2.4.31_memleak.tar.gz Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e) OpenLDAP 2.4.31 compiled in 64-bit with BerkeleyDB 5.3.15 appears to exhibit a memory leak while replicating the full database from another node in MMR. A two-node MMR configuration has been set up. Node 1 is full populated with data, approximately 338k DNs, which occupies around 1G on-disk (including bdb __db.* and log.* files). Node 1 is brought up and on a 64-bit system occupies around 5.5G VM and 4.7G RSS. Node 2 is initialized with a copy of cn=config (slapcat/slapadd method) and brought up with an empty database to begin replication. Over the course of the replication, node 2's slapd will grow continuously. On the one occasion it managed to "finish" the replication (with the test database), node 2's slapd occupied 14G VM and approximately 6G RSS. I've included a link to the test kit I put together. This includes a fairly large, anonimized database, as well as a simplified copy of the configuration. I've left in the sendmail and misc schemas but removed irrelevant local schemas. Also included are the DB_CONFIGs used for the main database and accesslog, and the configuration scripts used for compiling both bdb and OpenLDAP. Steps to reproduce: - Compile and install bdb and OpenLDAP with options the same as in the config-db.sh and config-ldap.sh scripts. - Initialize configuration on node 1 and 2 using "slapadd -F etc/slapd.d -b cn=config -l slapd-conf.ldif". - Initialize main DB on node 1 using "slapadd -l test_dit.ldif" - Start node 1. The slapd process should stabilize at around 5G VM in use. - Start node 2 and allow it to begin replication. I've tested with node 2 on both RHEL6 and on Solaris 10. In both cases, node 2's slapd became extremely bloated over the course of several hours. Only the Solaris SPARC box was able to complete the replication, stabilizing at 14G VM used. The Redhat x86 box continued to grow far beyond the 16G swap limit and was killed by the OS. I've attempted to use the Solaris libumem tools to trace the memory leak, using gcore on the running process and "::findleaks -dv" within mdb running on the core. I've included the report generated in case it provides any useful information as "mdb_findleaks_analysis.txt". Disregard if you wish. (I apologize for the large test LDIF. I wanted something to definitively show the problem so didn't want to trim it too much...)

1 0

(ITS#7291) [PATCH] MozNSS: read pin from file file can cause infinite loop
by jvcelak＠redhat.com 06 Jun '12

06 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120606-moznss-read-pin-from-file-… Submission from: (NULL) (209.132.186.34) The buffer allocated for reading password (pin) file has to be initialized with zeros, or we need to append zero at the end of the file. Otherwise we might read initialized memory and consider it to be a password. In this situation, all incoming TLS connections can hang. Attached patch fixes this bug. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following 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.

1 0

(ITS#7290) ldap_int_initialize() routine doesn't setup debug-level when calling ldap_int_initialize_global_options() routine
by sheng-yu.chen＠hp.com 06 Jun '12

06 Jun '12

Full_Name: Sheng-Yu.Chen Version: all OS: Windows7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.195.201.86) 1. Initialize the OpenLDAP debug-level by call ldap_set_option(NULL, LBER_OPT_DEBUG_LEVEL, 127). Note, ldap_set_option() is the first call to OpenLDAP libraries which would trigger the ldap_int_initialize() 2. In ldap_int_initialize(), OpenLDAP will call ldap_int_initialize_global_options(gopts, NULL), which means it would ignore the debug-level value 3. So the result is all the debug information happened in ldap_int_initialize_global_options() WILL be ignored.

1 0

Re: (ITS#7289) Mozilla NSS: cipher suite selection by name may be ignored
by tim.strobell.ctr＠nrl.navy.mil 05 Jun '12

05 Jun '12

Forgot to add that this bug is (was) masked by ITS#7285.

1 0

(ITS#7289) Mozilla NSS: cipher suite selection by name may be ignored
by tim.strobell.ctr＠nrl.navy.mil 05 Jun '12

05 Jun '12

Full_Name: Tim Strobell Version: HEAD OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/tim-strobell-2012060501.patch Submission from: (NULL) (2001:480:20:112:210:18ff:fe19:b000) Under certain circumstances, cipher suite selection by name ("OpenSSL name") may inadvertently cause any additional named cipher selections to be ignored. In tls_m.c:625... for (i=0; i<ciphernum; i++) { if (!strcmp(ciphers_def[i].ossl_name, cipher) && cipher_list[1] != -1) cipher_list[i] = action; } The index into cipher_list on line 627 is 1 (one) but should be i (eye). Any cipher selection that disables RC2-CBC-MD5 (cipher_list[1]) will not add/subtract/disable (action = 1, 0, -1 resp.) any further named ciphers in the list.

1 0

(ITS#7288) Doc update for MemberOf Overlay: add cn=config info
by openldap＠stompro.org 05 Jun '12

05 Jun '12

Full_Name: Josh Stompro Version: HEAD OS: Debian URL: ftp://ftp.openldap.org/incoming/josh-stompro-120605.patch Submission from: (NULL) (216.239.28.98) I uploaded a patch to openldap incoming ftp server name josh-stompro-120605.patch. This patch updates the man page for the MemberOf Overlay to include cn=config style instructions, and update the config option names so they comply with the cn=config style. I had to resort to google to figure out how to add this overlay since I'm not all that familiar with the cn=config format yet, and the documentation doesn't make it easy to figure out. I found an article on serverfault[1] that had the examples I needed to get it to work. This is my attempt to make it easier for the next individual. I, Josh Stompro, hereby place the following 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. 1 - http://serverfault.com/questions/73213/how-do-i-configure-reverse-group-mem…

1 0

Re: (ITS#7286) Malformed search filter to back-ldap/slapo-rwm crashes slapd
by masarati＠aero.polimi.it 05 Jun '12

05 Jun '12

On 06/05/2012 12:48 PM, hyc(a)symas.com wrote: > gahaverkamp(a)lbl.gov wrote: >> --e89a8fb1fbfae973ef04c1b0bad6 >> Content-Type: text/plain; charset=ISO-8859-1 >> >> I thought I had, but I now see that I left off "full". >> >> (gdb) bt full > > We slso need to see the slapd config. Without carefully looking at it, it could be related to reinstalling the original context because of the error. See ITS#6166. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

Re: (ITS#7286) Malformed search filter to back-ldap/slapo-rwm crashes slapd
by hyc＠symas.com 05 Jun '12

05 Jun '12

gahaverkamp(a)lbl.gov wrote: > --e89a8fb1fbfae973ef04c1b0bad6 > Content-Type: text/plain; charset=ISO-8859-1 > > I thought I had, but I now see that I left off "full". > > (gdb) bt full We slso need to see the slapd config. -- -- 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#7287) [PATCH] MozNSS: do not overwrite error in tlsm_verify_cert
by hyc＠symas.com 05 Jun '12

05 Jun '12

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: git master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20120605-moznss-overwrite-error-in-… > Submission from: (NULL) (209.132.186.34) > > > If the peer certificate verification fails and the certificate does not contain > Basic Constraint Extension, wrong TLS error message is reported by the library. > In addition, TLS_REQCERT=never does not work in this situation. This is caused > by overwriting the original error code in tlsm_verify_cert() function. > > Attached patch fixes this behavior. Applied to master. > > Old version: > > $ ldapsearch -x -ZZ > ldap_start_tls: Connect error (-11) > additional info: TLS error -8157:Certificate extension not found. > > Fixed version: > > $ ldapsearch -x -ZZ > ldap_start_tls: Connect error (-11) > additional info: TLS error -8172:Peer's certificate issuer has been > marked as not trusted by the user. > > > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by Red > Hat. Red Hat has not assigned rights and/or interest in this work to any party. > I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under > the following terms. > > Red Hat hereby place the following 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#7285) Mozilla NSS: default cipher suite always selected
by hyc＠symas.com 05 Jun '12

05 Jun '12

jvcelak(a)redhat.com wrote: > The patch is fine. I was just about to send exactly the same. We have a > report in our bugzilla for this. Thanks for the confirmation, fixed now in master. > > On Monday 04 of June 2012 21:56:08, tim.strobell.ctr(a)nrl.navy.mil wrote: >> Full_Name: Tim Strobell >> Version: HEAD >> OS: RHEL6 >> URL: ftp://ftp.openldap.org/incoming/tim-strobell-2012060401.patch >> Submission from: (NULL) (2001:480:20:112:210:18ff:fe19:b000) >> >> >> When using NSS, the default cipher suite selection is used even when >> TLSCipherSuite is explicitly specified. This behavior was introduced in the >> patch provided in ITS#6790. >> >> At tls_m.c:2221... >> >> if ( lt->lt_ciphersuite && >> tlsm_parse_ciphers( ctx, lt->lt_ciphersuite )) { >> [ error, return ] >> } else if ( tlsm_parse_ciphers( ctx, "DEFAULT" ) ) { >> [ error, return ] >> } >> >> tlsm_parse_ciphers returns 0 on success; the else path is always followed >> and overrides the previous cipher suite selection. > > > -- -- 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

(ITS#7287) [PATCH] MozNSS: do not overwrite error in tlsm_verify_cert
by jvcelak＠redhat.com 05 Jun '12

05 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120605-moznss-overwrite-error-in-… Submission from: (NULL) (209.132.186.34) If the peer certificate verification fails and the certificate does not contain Basic Constraint Extension, wrong TLS error message is reported by the library. In addition, TLS_REQCERT=never does not work in this situation. This is caused by overwriting the original error code in tlsm_verify_cert() function. Attached patch fixes this behavior. Old version: $ ldapsearch -x -ZZ ldap_start_tls: Connect error (-11) additional info: TLS error -8157:Certificate extension not found. Fixed version: $ ldapsearch -x -ZZ ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following 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.

1 0

Re: (ITS#7285) Mozilla NSS: default cipher suite always selected
by jvcelak＠redhat.com 05 Jun '12

05 Jun '12

The patch is fine. I was just about to send exactly the same. We have a report in our bugzilla for this. On Monday 04 of June 2012 21:56:08, tim.strobell.ctr(a)nrl.navy.mil wrote: > Full_Name: Tim Strobell > Version: HEAD > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/tim-strobell-2012060401.patch > Submission from: (NULL) (2001:480:20:112:210:18ff:fe19:b000) > > > When using NSS, the default cipher suite selection is used even when > TLSCipherSuite is explicitly specified. This behavior was introduced in the > patch provided in ITS#6790. > > At tls_m.c:2221... > > if ( lt->lt_ciphersuite && > tlsm_parse_ciphers( ctx, lt->lt_ciphersuite )) { > [ error, return ] > } else if ( tlsm_parse_ciphers( ctx, "DEFAULT" ) ) { > [ error, return ] > } > > tlsm_parse_ciphers returns 0 on success; the else path is always followed > and overrides the previous cipher suite selection.

1 0

Re: (ITS#7286) Malformed search filter to back-ldap/slapo-rwm crashes slapd
by gahaverkamp＠lbl.gov 04 Jun '12

04 Jun '12

--e89a8fb1fbfae973ef04c1b0bad6 Content-Type: text/plain; charset=ISO-8859-1 I thought I had, but I now see that I left off "full". (gdb) bt full #0 0x0000003f6987a31c in free () from /lib64/libc.so.6 No symbol table info available. #1 0x000000000043ca3e in ava_free (op=0x7fffe8002970, ava=0x7fffe8002e50, freeit=1) at ava.c:50 No locals. #2 0x000000000042453a in filter_free_x (op=0x7fffe8002970, f=0x7fffe8002ed0, freeme=1) at filter.c:531 p = <value optimized out> next = <value optimized out> #3 0x0000000000423127 in do_search (op=0x7fffe8002970, rs=0x7ffff640b950) at search.c:260 base = {bv_len = 10, bv_val = 0x7fffe8002707 "cn=example"} siz = 1 off = <value optimized out> i = <value optimized out> #4 0x0000000000420cfb in connection_operation (ctx=0x7ffff640bab0, arg_v=0x7fffe8002970) at connection.c:1150 rc = 80 cancel = <value optimized out> op = 0x7fffe8002970 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 1, sr_err = 0, sr_matched = 0x0, sr_text = 0x56d3ae "massaged filter parse error", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7ffff6c103d0 memctx = 0x7fffe8000a80 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #5 0x00000000004214d5 in connection_read_thread (ctx=0x7ffff640bab0, argv=<value optimized out>) at connection.c:1286 rc = <value optimized out> cri = {op = 0x7fffe8002970, func = 0, arg = 0x0, ctx = 0x7ffff640bab0, nullop = <value optimized out>} s = <value optimized out> #6 0x000000000050cc30 in ldap_int_thread_pool_wrapper (xpool=0x8809a0) at tpool.c:688 pool = 0x8809a0 task = 0x7ffff00008c0 work_list = <value optimized out> ctx = {ltu_id = 140737324828416, ltu_key = {{ltk_key = 0x41fa50, ltk_data = 0x7fffe8002900, ltk_free = 0x41fb20 <conn_counter_destroy>}, {ltk_key = 0x473490, ltk_data = 0x7fffe8000a80, ltk_free = 0x4734b0 <slap_sl_mem_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 30 times>}} kctx = <value optimized out> keyslot = 923 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #7 0x0000003f69c077f1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #8 0x0000003f698e592d in clone () from /lib64/libc.so.6 No symbol table info available. On Mon, Jun 4, 2012 at 7:17 PM, <quanah(a)zimbra.com> wrote: > --On Tuesday, June 05, 2012 1:50 AM +0000 gahaverkamp(a)lbl.gov wrote: > > > Full_Name: Greg Haverkamp > > Version: 2.4.31 > > OS: RHEL 6.2/OS X 10.7 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (128.3.10.46) > > > > > > When a request to a massaged suffix is made of back-ldap/slapo-rwm with a > > malformed filter, slapd crashes on the two tested platforms (RHEL 6.2/OS > X > > 10.7). The last bits of the debug log and the backtrace are below: > > I would suggest putting slapd under gdb and providing a backtrace. > > See <http://www.openldap.org/faq/data/cache/59.html> > > --Quanah > > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > --e89a8fb1fbfae973ef04c1b0bad6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I thought I had, but I now see that I left off "full".<div><br></= div><div><div>(gdb) bt full</div><div>#0 =A00x0000003f6987a31c in free () f= rom /lib64/libc.so.6</div><div>No symbol table info available.</div><div>#1= =A00x000000000043ca3e in ava_free (op=3D0x7fffe8002970, ava=3D0x7fffe8002e= 50, freeit=3D1) at ava.c:50</div> <div>No locals.</div><div>#2 =A00x000000000042453a in filter_free_x (op=3D0= x7fffe8002970, f=3D0x7fffe8002ed0, freeme=3D1) at filter.c:531</div><div>= =A0 =A0 =A0 =A0 p =3D <value optimized out></div><div>=A0 =A0 =A0 =A0= next =3D <value optimized out></div> <div>#3 =A00x0000000000423127 in do_search (op=3D0x7fffe8002970, rs=3D0x7ff= ff640b950) at search.c:260</div><div>=A0 =A0 =A0 =A0 base =3D {bv_len =3D 1= 0, bv_val =3D 0x7fffe8002707 "cn=3Dexample"}</div><div>=A0 =A0 = =A0 =A0 siz =3D 1</div><div>=A0 =A0 =A0 =A0 off =3D <value optimized out= ></div> <div>=A0 =A0 =A0 =A0 i =3D <value optimized out></div><div>#4 =A00x00= 00000000420cfb in connection_operation (ctx=3D0x7ffff640bab0, arg_v=3D0x7ff= fe8002970) at connection.c:1150</div><div>=A0 =A0 =A0 =A0 rc =3D 80</div><d= iv>=A0 =A0 =A0 =A0 cancel =3D <value optimized out></div> <div>=A0 =A0 =A0 =A0 op =3D 0x7fffe8002970</div><div>=A0 =A0 =A0 =A0 rs =3D= {sr_type =3D REP_RESULT, sr_tag =3D 101, sr_msgid =3D 1, sr_err =3D 0, sr_= matched =3D 0x0, sr_text =3D 0x56d3ae "massaged filter parse error&quo= t;, sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D {sru_search =3D {r_entry = =3D 0x0, r_attr_flags =3D 0, r_operational_attrs =3D 0x0,=A0</div> <div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 r_attrs =3D 0x0, r_nentries =3D 0, r_v2ref= =3D 0x0}, sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid = =3D 0x0, r_rspdata =3D 0x0}}, sr_flags =3D 0}</div><div>=A0 =A0 =A0 =A0 tag= =3D 99</div><div>=A0 =A0 =A0 =A0 opidx =3D SLAP_OP_SEARCH</div> <div>=A0 =A0 =A0 =A0 conn =3D 0x7ffff6c103d0</div><div>=A0 =A0 =A0 =A0 memc= tx =3D 0x7fffe8000a80</div><div>=A0 =A0 =A0 =A0 memctx_null =3D 0x0</div><d= iv>=A0 =A0 =A0 =A0 memsiz =3D 1048576</div><div>=A0 =A0 =A0 =A0 __PRETTY_FU= NCTION__ =3D "connection_operation"</div> <div>#5 =A00x00000000004214d5 in connection_read_thread (ctx=3D0x7ffff640ba= b0, argv=3D<value optimized out>) at connection.c:1286</div><div>=A0 = =A0 =A0 =A0 rc =3D <value optimized out></div><div>=A0 =A0 =A0 =A0 cr= i =3D {op =3D 0x7fffe8002970, func =3D 0, arg =3D 0x0, ctx =3D 0x7ffff640ba= b0, nullop =3D <value optimized out>}</div> <div>=A0 =A0 =A0 =A0 s =3D <value optimized out></div><div>#6 =A00x00= 0000000050cc30 in ldap_int_thread_pool_wrapper (xpool=3D0x8809a0) at tpool.= c:688</div><div>=A0 =A0 =A0 =A0 pool =3D 0x8809a0</div><div>=A0 =A0 =A0 =A0= task =3D 0x7ffff00008c0</div> <div>=A0 =A0 =A0 =A0 work_list =3D <value optimized out></div><div>= =A0 =A0 =A0 =A0 ctx =3D {ltu_id =3D 140737324828416, ltu_key =3D {{ltk_key = =3D 0x41fa50, ltk_data =3D 0x7fffe8002900, ltk_free =3D 0x41fb20 <conn_c= ounter_destroy>}, {ltk_key =3D 0x473490, ltk_data =3D 0x7fffe8000a80, lt= k_free =3D 0x4734b0 <slap_sl_mem_destroy>}, {ltk_key =3D 0x0,=A0</div= > <div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 ltk_data =3D 0x0, ltk_free =3D 0} <repe= ats 30 times>}}</div><div>=A0 =A0 =A0 =A0 kctx =3D <value optimized o= ut></div><div>=A0 =A0 =A0 =A0 keyslot =3D 923</div><div>=A0 =A0 =A0 =A0 = hash =3D <value optimized out></div><div> =A0 =A0 =A0 =A0 __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper&= quot;</div><div>#7 =A00x0000003f69c077f1 in start_thread () from /lib64/lib= pthread.so.0</div><div>No symbol table info available.</div><div>#8 =A00x00= 00003f698e592d in clone () from /lib64/libc.so.6</div> <div>No symbol table info available.</div></div><div><br></div><div><br><di= v><br><div class=3D"gmail_quote">On Mon, Jun 4, 2012 at 7:17 PM, <span dir= =3D"ltr"><<a href=3D"mailto:quanah@zimbra.com" target=3D"_blank">quanah@= zimbra.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">--On= Tuesday, June 05, 2012 1:50 AM +0000 <a href=3D"mailto:gahaverkamp@lbl.gov= ">gahaverkamp(a)lbl.gov</a> wrote:<br> <br> > Full_Name: Greg Haverkamp<br> > Version: 2.4.31<br> > OS: RHEL 6.2/OS X 10.7<br> > URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ft= p://ftp.openldap.org/incoming/</a><br> > Submission from: (NULL) (128.3.10.46)<br> ><br> ><br> > When a request to a massaged suffix is made of back-ldap/slapo-rwm wit= h a<br> > malformed filter, slapd crashes on the two tested platforms (RHEL 6.2/= OS X<br> > 10.7). =A0The last bits of the debug log and the backtrace are below:<= br> <br> I would suggest putting slapd under gdb and providing a backtrace.<br> <br> See <<a href=3D"http://www.openldap.org/faq/data/cache/59.html" target= =3D"_blank">http://www.openldap.org/faq/data/cache/59.html</a>><br> <br> --Quanah<br> <br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Sr. Member of Technical Staff<br> Zimbra, Inc<br> A Division of VMware, Inc.<br> --------------------<br> Zimbra :: =A0the leader in open source messaging and collaboration<br> <br> <br> </div></div></blockquote></div><br></div></div> --e89a8fb1fbfae973ef04c1b0bad6--

1 0

Re: (ITS#7286) Malformed search filter to back-ldap/slapo-rwm crashes slapd
by quanah＠zimbra.com 04 Jun '12

04 Jun '12

--On Tuesday, June 05, 2012 1:50 AM +0000 gahaverkamp(a)lbl.gov wrote: > Full_Name: Greg Haverkamp > Version: 2.4.31 > OS: RHEL 6.2/OS X 10.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.3.10.46) > > > When a request to a massaged suffix is made of back-ldap/slapo-rwm with a > malformed filter, slapd crashes on the two tested platforms (RHEL 6.2/OS X > 10.7). The last bits of the debug log and the backtrace are below: I would suggest putting slapd under gdb and providing a backtrace. See <http://www.openldap.org/faq/data/cache/59.html> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7286) Malformed search filter to back-ldap/slapo-rwm crashes slapd
by gahaverkamp＠lbl.gov 04 Jun '12

04 Jun '12

Full_Name: Greg Haverkamp Version: 2.4.31 OS: RHEL 6.2/OS X 10.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.3.10.46) When a request to a massaged suffix is made of back-ldap/slapo-rwm with a malformed filter, slapd crashes on the two tested platforms (RHEL 6.2/OS X 10.7). The last bits of the debug log and the backtrace are below: [New Thread 0x7ffff640c700 (LWP 4520)] 4fcd62a8 >>> slap_listener(ldap://*:3389) 4fcd62a8 connection_get(13) 4fcd62a8 connection_get(13): got connid=1000 4fcd62a8 connection_read(13): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: 30 44 02 01 01 63 3f 04 0D...c?. ldap_read: want=62, got=62 0000: 0a 63 6e 3d 65 78 61 6d 70 6c 65 0a 01 02 0a 01 .cn=example..... 0010: 00 02 01 00 02 01 00 01 01 00 a3 13 04 04 66 6f ..............fo 0020: 6f 20 04 0b 67 61 68 61 76 65 72 6b 61 6d 70 30 o ..gahaverkamp0 0030: 0d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 ...objectClass ber_get_next: tag 0x30 len 68 contents: 4fcd62a8 op tag 0x63, time 1338860200 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable 4fcd62a8 conn=1000 op=0 do_search ber_scanf fmt ({miiiib) ber: 4fcd62a8 >>> dnPrettyNormal: <cn=example> => ldap_bv2dn(cn=example,0) <= ldap_bv2dn(cn=example)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=example)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=example)=0 4fcd62a8 <<< dnPrettyNormal: <cn=example>, <cn=example> 4fcd62a8 SRCH "cn=example" 2 04fcd62a8 0 0 0 ber_scanf fmt ({mm}) ber: 4fcd62a8 filter: (?foo =gahaverkamp) ber_scanf fmt ({M}}) ber: 4fcd62a8 attrs:4fcd62a8 objectClass4fcd62a8 4fcd62a8 ==> limits_get: conn=1000 op=0 self="[anonymous]" this="cn=example" 4fcd62a8 ==> rewrite_context_apply [depth=1] string='cn=example' 4fcd62a8 ==> rewrite_rule_apply rule='((.+),)?cn=example$' string='cn=example' [1 pass(es)] 4fcd62a8 ==> rewrite_context_apply [depth=1] res={0,'dc=lbl,dc=gov'} 4fcd62a8 [rw] searchDN: "cn=example" -> "dc=lbl,dc=gov" 4fcd62a8 >>> dnPrettyNormal: <dc=lbl,dc=gov> => ldap_bv2dn(dc=lbl,dc=gov,0) <= ldap_bv2dn(dc=lbl,dc=gov)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=lbl,dc=gov)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=lbl,dc=gov)=0 4fcd62a8 <<< dnPrettyNormal: <dc=lbl,dc=gov>, <dc=lbl,dc=gov> 4fcd62a8 ==> rewrite_context_apply [depth=1] string='(foo =gahaverkamp)' 4fcd62a8 ==> rewrite_context_apply [depth=1] res={0,'NULL'} [rw] searchFilter: "(foo =gahaverkamp)" -> "(foo =gahaverkamp)" put_filter: "(foo =gahaverkamp)" put_filter: simple put_simple_filter: "foo =gahaverkamp" 4fcd62a8 send_ldap_result: conn=1000 op=0 p=3 4fcd62a8 send_ldap_result: err=0 matched="" text="massaged filter parse error" 4fcd62a8 send_ldap_response: msgid=1 tag=101 err=0 ber_flush2: 41 bytes to sd 13 ldap_write: want=41, written=41 0000: 30 27 02 01 01 65 22 0a 01 00 04 00 04 1b 6d 61 0'...e".......ma 0010: 73 73 61 67 65 64 20 66 69 6c 74 65 72 20 70 61 ssaged filter pa 0020: 72 73 65 20 65 72 72 6f 72 rse error Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff640c700 (LWP 4520)] 0x0000003f6987a31c in free () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install cyrus-sasl-gssapi-2.1.23-13.el6.x86_64 cyrus-sasl-lib-2.1.23-13.el6.x86_64 cyrus-sasl-plain-2.1.23-13.el6.x86_64 db4-4.7.25-16.el6.x86_64 glibc-2.12-1.47.el6_2.5.x86_64 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6_2.1.x86_64 libcom_err-1.41.12-11.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-20.el6_2.1.x86_64 zlib-1.2.3-27.el6.x86_64 (gdb) bt #0 0x0000003f6987a31c in free () from /lib64/libc.so.6 #1 0x000000000043ca3e in ava_free (op=0x7fffe8002970, ava=0x7fffe8002e50, freeit=1) at ava.c:50 #2 0x000000000042453a in filter_free_x (op=0x7fffe8002970, f=0x7fffe8002ed0, freeme=1) at filter.c:531 #3 0x0000000000423127 in do_search (op=0x7fffe8002970, rs=0x7ffff640b950) at search.c:260 #4 0x0000000000420cfb in connection_operation (ctx=0x7ffff640bab0, arg_v=0x7fffe8002970) at connection.c:1150 #5 0x00000000004214d5 in connection_read_thread (ctx=0x7ffff640bab0, argv=<value optimized out>) at connection.c:1286 #6 0x000000000050cc30 in ldap_int_thread_pool_wrapper (xpool=0x8809a0) at tpool.c:688 #7 0x0000003f69c077f1 in start_thread () from /lib64/libpthread.so.0 #8 0x0000003f698e592d in clone () from /lib64/libc.so.6 ldapsearch takes care of handling the bad search filter. However, the problem arose when one of our developers miscoded the search filter (badly). A short bit of Jython (utilizing the UnboundID ldap sdk) that can cause the crash is here: from com.unboundid.ldap.sdk import LDAPConnection from com.unboundid.ldap.sdk import SearchScope from com.unboundid.ldap.sdk import SearchResult from com.unboundid.ldap.sdk import LDAPURL attributes = ['objectClass'] ldap_url = "ldap://10.0.228.135:3389" url = LDAPURL(ldap_url) ldap_conn = LDAPConnection(url.getHost(), url.getPort()) #search_result = ldap_conn.search('ou=people,o=lawrence berkeley laboratory,c=us', SearchScope.SUB, '(?uid = \'gahaverkamp\')', attributes) search_result = ldap_conn.search('cn=example', SearchScope.SUB, '(foo =gahaverkamp)', attributes) entries = search_result.getSearchEntries() The actual contents of the filter don't seem to matter too much, so long as filter is bad. The original one sent by the developer resembles the commented line in the script above.

1 0

(ITS#7285) Mozilla NSS: default cipher suite always selected
by tim.strobell.ctr＠nrl.navy.mil 04 Jun '12

04 Jun '12

Full_Name: Tim Strobell Version: HEAD OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/tim-strobell-2012060401.patch Submission from: (NULL) (2001:480:20:112:210:18ff:fe19:b000) When using NSS, the default cipher suite selection is used even when TLSCipherSuite is explicitly specified. This behavior was introduced in the patch provided in ITS#6790. At tls_m.c:2221... if ( lt->lt_ciphersuite && tlsm_parse_ciphers( ctx, lt->lt_ciphersuite )) { [ error, return ] } else if ( tlsm_parse_ciphers( ctx, "DEFAULT" ) ) { [ error, return ] } tlsm_parse_ciphers returns 0 on success; the else path is always followed and overrides the previous cipher suite selection.

1 0

Re: (ITS#7284) [PATCH] slappasswd: Add support loading a dynamically loadable module
by hyc＠symas.com 31 May '12

31 May '12

fumiyas(a)osstech.co.jp wrote: > Full_Name: SATOH Fumiyasu > Version: master, 2.4.31 > OS: > URL: https://gist.github.com/2841031 > Submission from: (NULL) (220.100.28.128) > > > This patch is for slappasswd to add "-o module-path=<pathspec>" and > "-o module-load=<filename>" options to load a dynamically loadable > password hash module (e.g., slapd-sha2). > > Thanks, added to 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#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by fumiyas＠osstech.co.jp 31 May '12

31 May '12

At Thu, 31 May 2012 08:43:30 +0200, Michael Ströder wrote: > I'm trying to build this module (make distclean before) from recent RE24 git > 0cfc487a70f2de40d9827b67949569653ee0e28a but it fails: > > $ make > cc -I../../../../include -Wall -g -c slapd-sha2.c > cc -I../../../../include -Wall -g -c sha2.c > cc -I../../../../include -shared -Wall -g slapd-sha2.o sha2.o -o slapd-sha2.so > /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: > slapd-sha2.o: relocation R_X86_64_32 against `.text' can not be used when > making a shared object; recompile with -fPIC See the above message. :-) > slapd-sha2.o: could not read symbols: Bad value > collect2: ld returned 1 exit status > make: *** [slapd-sha2.so] Error 1 > > Do I have to tweak the Makefile? Add -fPIC to $CCFLAGS in Makefile if you are using GCC. -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 30 May '12

30 May '12

This is a cryptographically signed message in MIME format. --------------ms060305000509010900080201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm trying to build this module (make distclean before) from recent RE24 = git 0cfc487a70f2de40d9827b67949569653ee0e28a but it fails: $ make cc -I../../../../include -Wall -g -c slapd-sha2.c cc -I../../../../include -Wall -g -c sha2.c cc -I../../../../include -shared -Wall -g slapd-sha2.o sha2.o -o slapd-sh= a2.so /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld= : slapd-sha2.o: relocation R_X86_64_32 against `.text' can not be used when= making a shared object; recompile with -fPIC slapd-sha2.o: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [slapd-sha2.so] Error 1 Do I have to tweak the Makefile? Ciao, Michael. --------------ms060305000509010900080201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUzMTA2NDMzMFowIwYJKoZIhvcNAQkEMRYE FC85H17zMN2jlPjKKQ1rj5hqS8WpMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAXbWKhps9kQkfGtZFzf7H79BV32CGHmWfLnjgZgGMaEyhcig7b3PDVVIc63qnRL5Q7chG AJBM8L2KwPIkfk+mlso3F9cZA2oDgmSttIVYv/2IZmKkH0Ed9K4+4LhUms8lxdJGdpaj2/dS iRFjPumGR5lHopiVa5s2YEfkry75T93hwawU6Lx5ZQ0wouuleysRAygsFaMO5r4ugp4nIX2Y 1Uqe+uyLl5fKwxSnKmfqZ24KpGGuqgrezurZDnFdAJbDF/4Gwe/EpViG28tDXx0zEMm+BejJ 4jTd7VjpUgj85QmoHTttzervjjuz5XVEf3SRdTmImTQrDgJP55zGZdKa6QAAAAAAAA== --------------ms060305000509010900080201--

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by fumiyas＠osstech.co.jp 30 May '12

30 May '12

At Wed, 30 May 2012 17:11:23 GMT, Kurt(a)OpenLDAP.org wrote: > > I wish the following command-line option for slappasswd to > > load dynamically loadable password hash modules: > > > > $ slappasswd -o module-load=slapd-sha2.la -h '{SSHA512}' > > ... > > > > $ slappasswd -o module-path=/path/to/lib/openldap \ > > -o module-load=slapd-sha2.la -h '{SSHA512}' > > This seems more appropriate approach to me than reading slapd.conf files. Users who use a particular module frequently can use an alias to reduce the typing overhead. I've created a patch. http://www.openldap.org/its/index.cgi?findid=7284 -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/

1 0

(ITS#7284) [PATCH] slappasswd: Add support loading a dynamically loadable module
by fumiyas＠osstech.co.jp 30 May '12

30 May '12

Full_Name: SATOH Fumiyasu Version: master, 2.4.31 OS: URL: https://gist.github.com/2841031 Submission from: (NULL) (220.100.28.128) This patch is for slappasswd to add "-o module-path=<pathspec>" and "-o module-load=<filename>" options to load a dynamically loadable password hash module (e.g., slapd-sha2).

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by Kurt＠OpenLDAP.org 30 May '12

30 May '12

On May 30, 2012, at 10:06 AM, fumiyas(a)osstech.co.jp wrote: > I wish the following command-line option for slappasswd to > load dynamically loadable password hash modules: > > $ slappasswd -o module-load=slapd-sha2.la -h '{SSHA512}' > ... > > $ slappasswd -o module-path=/path/to/lib/openldap \ > -o module-load=slapd-sha2.la -h '{SSHA512}' This seems more appropriate approach to me than reading slapd.conf files. Users who use a particular module frequently can use an alias to reduce the typing overhead. -- Kurt

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by fumiyas＠osstech.co.jp 30 May '12

30 May '12

Hi, I wish the following command-line option for slappasswd to load dynamically loadable password hash modules: $ slappasswd -o module-load=slapd-sha2.la -h '{SSHA512}' ... $ slappasswd -o module-path=/path/to/lib/openldap \ -o module-load=slapd-sha2.la -h '{SSHA512}' ... At Wed, 30 May 2012 13:45:48 GMT, Kurt(a)OpenLDAP.org wrote: > While if I needed some scheme only in contrib I might resort to other means to generate the hash (such as a little perl), I don't object to slappasswd, when requested by option, reading the configuration, loading the modules, and generating the hash. I would only object if slappasswd did this by default, as that would cause me to have to use other means even for core schemes. I've revised the patch: https://gist.github.com/2632560 With this patch: $ slappasswd Same as the original behavior (do not read any config) $ slappasswd -f /path/to/slapd.conf Read the specified slapd.conf $ slappasswd -f - Read the default slapd.conf -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/

1 0

Re: (ITS#7271) Don't clobber SASL_NOCANON in clients/tools/common.c
by hyc＠symas.com 30 May '12

30 May '12

W. Trevor King wrote: > On Wed, May 30, 2012 at 06:14:38AM -0700, Howard Chu wrote: >> Ideally the command line option should have been able to set this >> explicitly to both true and false, to allow complete control over >> the option. But I'm not particularly concerned either way. Since the >> option currently can only be set to true, it would be sufficient to >> just check for nocanon != 0 before calling ldap_set_option. > > My personal goal here is to not need to bother with command line > options, so I'm fine with this less general solution. Another patch > (only set the option with an explicit `-N`) attached. > > --- > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by W. Trevor King wking(a)tremily.us. I have > not assigned rights and/or interest in this work to any party. > > I, W. Trevor King, hereby place the following 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. > Thanks, added to 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#7271) Don't clobber SASL_NOCANON in clients/tools/common.c
by wking＠tremily.us 30 May '12

30 May '12

--oLBj+sq0vYjzfsbl Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 30, 2012 at 06:14:38AM -0700, Howard Chu wrote: > Ideally the command line option should have been able to set this > explicitly to both true and false, to allow complete control over > the option. But I'm not particularly concerned either way. Since the > option currently can only be set to true, it would be sufficient to > just check for nocanon !=3D 0 before calling ldap_set_option. My personal goal here is to not need to bother with command line options, so I'm fine with this less general solution. Another patch (only set the option with an explicit `-N`) attached. --- The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by W. Trevor King wking(a)tremily.us. I have not assigned rights and/or interest in this work to any party. I, W. Trevor King, hereby place the following 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. --=20 This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tool-nocanon.patch" Content-Transfer-Encoding: quoted-printable diff --git a/clients/tools/common.c b/clients/tools/common.c index 9c98b62..e928fb2 100644 --- a/clients/tools/common.c +++ b/clients/tools/common.c @@ -1410,12 +1410,13 @@ dnssrv_free:; =20 #ifdef HAVE_CYRUS_SASL /* canon */ - if( ldap_set_option( ld, LDAP_OPT_X_SASL_NOCANON, - nocanon ? LDAP_OPT_ON : LDAP_OPT_OFF ) !=3D LDAP_OPT_SUCCESS ) - { - fprintf( stderr, "Could not set LDAP_OPT_X_SASL_NOCANON %s\n", - nocanon ? "on" : "off" ); - tool_exit( ld, EXIT_FAILURE ); + if( nocanon ) { + if( ldap_set_option( ld, LDAP_OPT_X_SASL_NOCANON, + LDAP_OPT_ON ) !=3D LDAP_OPT_SUCCESS ) + { + fprintf( stderr, "Could not set LDAP_OPT_X_SASL_NOCANON on\n" ); + tool_exit( ld, EXIT_FAILURE ); + } } #endif if( ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ) --yrj/dFKFPuw6o+aM-- --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBAgAGBQJPxjviAAoJEEUbTsx0l5OM4+AQALnDBr4YL5g8BIgsU7Fvea1O 3cCh+arj8S3mFsltqKnvOZTRqnPp9yafmCKzLnb8DP3xstXFwF3A/J1o8+Ptzi9d v5EbYd/+jUp1kQBAQHclS87OwjijgHuZtRZxcJXbh4CrV7T/FG6byiVvpFpxR06O ug306vFhqhBk1FpbUJU+R0u7gzUaTjhW4O/RE9kPEaqnkSSfd+NuCF1L8ZHzmAOc xA8gJgUVP5GOgfrZeoQjuyO+mGOVpHPjcybs1VThyhbLWwPKb/RExdTa/0x+A/p8 hVlM9C9SGr1UC3QQaboSON0rhP4UjHc/HCA53Ijgw+vCr0KiaUDjaiG83ydj0EfY Q71IF/PY286lUCLorw1ZJqtAP1dRbpWCk+45A4ZoMR6zWgUUX1L27v7gD5pUQZWW J85OU8D1OFuH1tYNXp+6VgiQpO5ofwQTaQo2puVOjwGpgjCjl1g69kWLjle9JvEv cRZ9wuT3rfVc9Ujv/Tqirw6cy+1QJopKjRlHcV1RX6j34RFBfc9qwcM/3BC1sMGD 2IDRte87sUAq+i3bM43iFujTI9AwUd3pAP/9x2D7tnrr4t5ixV+MBtaNmWtblBos XHeReDSakxipIfBxJtQTSTeKrb7VPS4d7RpUEg5etXLIxVaJyVpSTl0G3b8tWwC0 yZySTz5NthLULma8573R =lyIG -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl--

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by Kurt＠OpenLDAP.org 30 May '12

30 May '12

On May 29, 2012, at 1:38 PM, michael(a)stroeder.com wrote: > Still you did not answer why SHA-1 is in and SHA-2 is out. Well, the general rule is simply all new hash schemes should go in contrib first. What you ask is for an exception to this general rule for SHA-2. I don't see the arguments for the exception being all that strong. Arguing it should be "in" because SHA-1 is "in" is a really poor argument. SHA-1 is "in" because it was grandfathered in. SHA-2, like any new hash scheme, is "out" because of the current practice to put new schemes in contrib. It's as simple as that, I think. I do note that there's many issues bring hashes into core. One key one is that core schemes ought to work with minimal 3rd party libraries, and that means without OpenSSL. So bringing these schemes also means, if we hold to this, bring in a SHA2 implementation into core... and that's gets, well, more involved. And that's one of reasons we have the core/contrib split. Anyways, I personally think no exception should be granted, these schemes should go into contrib like any other new hash scheme would. I've thought a bit about whether slappasswd should or should not load modules. I stand against slapppasswd reading slapd configuration by default. I would not object to reading slapd configuration when specifically requested by the user (by a command line argument). I generally run slappasswd (for setup purposes) as a user which has no access to slapd configuration. This not only for convenience, but for security reasons (limit programs which can read the configuration, as the configuration contains sensitive information). While if I needed some scheme only in contrib I might resort to other means to generate the hash (such as a little perl), I don't object to slappasswd, when requested by option, reading the configuration, loading the modules, and generating the hash. I would only object if slappasswd did this by default, as that would cause me to have to use other means even for core schemes. -- Kurt

1 0

Re: (ITS#7276) [PATCH] MozNSS: allow CA certdb together with PEM CA bundle file
by hyc＠symas.com 30 May '12

30 May '12

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20120518-update-nss-allow-ca-certdb… > Submission from: (NULL) (209.132.186.34) > > > With Mozilla NSS crypto backend: > > Prior to this patch, if TLS_CACERTDIR was set to Mozilla NSS certificate > database and TLS_CACERT was set to a PEM bundle file with CA > certificates, the PEM file content was not loaded. > > With this patch and the same settings, OpenLDAP can verify certificates > which are signed by CAs stored both in certdb and PEM bundle file. Thanks for the patch, added to master. > > This problem was found with FreeIPA which is setting CA PEM bundle using > ldap_set_option(&ld, LDAP_OPT_X_TLS_CACERTFILE, ...), while TLS_CACERTDIR with > certdb is set in system ldap.conf file. > > > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by Red > Hat. Red Hat has not assigned rights and/or interest in this work to any party. > I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under > the following terms. > > Red Hat hereby place the following 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#7271) Don't clobber SASL_NOCANON in clients/tools/common.c
by hyc＠symas.com 30 May '12

30 May '12

wking(a)tremily.us wrote: > Full_Name: W. Trevor King > Version: git commit 22bf5188 > OS: Gentoo > URL: http://blog.tremily.us/posts/LDAP/tool-nocanon.patch > Submission from: (NULL) (72.68.88.202) > > > The ldap.conf SASL_NOCANON configuration option (or LDAPSASL_NOCANON environment > variable) should set the default behaviour for OpenLDAP tools such as > ldapwhoami. This configuration option should allow users to use the tools > without having to use the matching command line option (-N). Unfortunately, the > current code sets the option to true/false after only querying the command line > option. > > I'm linking to a patch that looks at the current value of the option first, and > if it's true, skips processing the command line option (which would either be a > redundant -N keeping the option true, or an absence of -N which implies the user > wants to use the configured value (true)). > > Another approach would be to set the initial value of nocanon to UNINITIALIZED > (-1?). Command line arguments could set nocanon to 1 (true, -N) or false (0, > --canon?). Then we would only call ldap_set_option if nocanon was not > UNINITIALIZED. > > I can work up a patch using this second approach if people prefer. If so, let > me know if you want me to define UNINITIALIZED, or to just use -1. > > I didn't check, but I would not be surprised if this same clobbering occurred > for other command line options. The only other boolean command line option is referrals, which is deprecated and has been undocumented for years. Not worth bothering over. Ideally the command line option should have been able to set this explicitly to both true and false, to allow complete control over the option. But I'm not particularly concerned either way. Since the option currently can only be set to true, it would be sufficient to just check for nocanon != 0 before calling ldap_set_option. -- -- 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#7270) Double free in ldap_int_initialize
by hyc＠symas.com 30 May '12

30 May '12

fdeweerdt(a)cloudmark.com wrote: > Full_Name: Frederik Deweerdt > Version: current HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Frederik-Deweerdt-120511.patch > Submission from: (NULL) (72.5.239.5) > > > [PATCH] Protect accesses to ldap_int_hostname with a mutex Thanks for the patch, now in git master. > > > Not protecting the accesses to ldap_int_hostname would lead to a double > free with the following trace: > > #7 0x0000003aca031d10 in abort () from /lib64/libc.so.6 > No symbol table info available. > #8 0x0000003aca06a99b in __libc_message () from /lib64/libc.so.6 > No symbol table info available. > #9 0x0000003aca0729d6 in free () from /lib64/libc.so.6 > No symbol table info available. > #10 0x000000328902333e in ldap_int_initialize () > from /usr/lib64/libldap-2.3.so.0 > No symbol table info available. > #11 0x000000328900c426 in ldap_create () from /usr/lib64/libldap-2.3.so.0 > No symbol table info available. > #12 0x000000328900ca0d in ldap_init () from /usr/lib64/libldap-2.3.so.0 > No symbol table info available. > > The race in init.c:ldap_int_initialize is as follows: > 646 char *name = ldap_int_hostname; > 647 > 648 ldap_int_hostname = ldap_pvt_get_fqdn( name ); > 649 > 650 if ( name != NULL && name != ldap_int_hostname ) { > 651 LDAP_FREE( name ); > 652 } > > - T1 and T2 enter ldap_int_initialize, both assign to name the current > address of ldap_int_hostname, say 0x1234. > - T1 and T2 call ldap_pvt_get_fqdn(), updating ldap_int_hostname to 0x1235 > and 0x1236 respectively. > - T1 and T2 reach the name != ldap_int_hostname check. In both threads > it's false, because 0x1235 != 0x1234 and 0x1236 != 0x1234, respectively. > - T1 and T2 both try to free 0x1234 => Crash. > --- > libraries/libldap/init.c | 2 ++ > libraries/libldap/ldap-int.h | 1 + > libraries/libldap/util-int.c | 3 +++ > 3 files changed, 6 insertions(+), 0 deletions(-) > > > -- -- 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#7283) Usage of private headers make building out-of-tree extensions painful
by hyc＠symas.com 30 May '12

30 May '12

guillomovitch(a)gmail.com wrote: > Full_Name: Guillaume Rousse > Version: any > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.93.30.10) > > > In order to build out of tree extensions, such as ppolicy external password > checker (http://ltb-project.org/wiki/documentation/openldap-ppolicy-check-password), > you need additional slapd headers, portable.h and slapd.h (and a bunch of > additional dependant ones), which are currently not installed, and thus > considered as private. > > A request to ship those headers was refused by fedora package maintainer, > precisely for this reason: > https://bugzilla.redhat.com/show_bug.cgi?id=812860 They gave the right answer. The slap.h header is private and subject to change without notice. > The situation ought to be clarified, and some kind of solution found, as > maintaining a custom slapd build just to be able to benefit from this > extensability is largely overkill. Probably this should be discussed on the openldap-devel mailing list. There's no straightforward solution to this request. In the case of the LTB password checker module, there's barely any need for slap.h; the module could easily be tweaked to avoid all references to it. -- -- 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#7279) Apparently mdb "approx" index generation failure for mdb_add for syncrepl consumer
by hyc＠symas.com 30 May '12

30 May '12

brandon.hume(a)dal.ca wrote: > Full_Name: Brandon Hume > Version: 2.4.31 > OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64 > URL: http://den.bofh.ca/~hume/mdb_approx_indexfail.tar > Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e) > > > An empty syncrepl consumer using mdb backend will suffer index generator > failures when populating its database from the provider and using "approx" index > options. The failure manifests in syslog (with olcLogLevel=Stats) as the > following: > > May 24 11:50:41 node2 slapd[25282]: null_callback : error code 0x50 > May 24 11:50:41 node2 slapd[25282]: syncrepl_entry: rid=001 be_add $DN failed > (80) > > These problems don't seem to occur when populating the provider using slapadd. > The problem only seems to manifest when the new entry arrives via syncrepl. > Playing with gdb, it seems like indexer() ends up being called with { bv_len = > 0, bv_val = "" } when indexing "givenName". Thanks for the report, fixed now in git master. slapadd also failed for me, so it wasn't quite the same behavior you reported. > > Could be because "givenName" on the troublesome entry is only one character? > > A minimalist DIT and config are provided in the tarfile in the link. The two > nodes are running in mirrormode, and I'm not sure if that makes a difference. The config is invalid; you have used the same RIDs multiple times. -- -- 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

(ITS#7283) Usage of private headers make building out-of-tree extensions painful
by guillomovitch＠gmail.com 30 May '12

30 May '12

Full_Name: Guillaume Rousse Version: any OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.93.30.10) In order to build out of tree extensions, such as ppolicy external password checker (http://ltb-project.org/wiki/documentation/openldap-ppolicy-check-password), you need additional slapd headers, portable.h and slapd.h (and a bunch of additional dependant ones), which are currently not installed, and thus considered as private. A request to ship those headers was refused by fedora package maintainer, precisely for this reason: https://bugzilla.redhat.com/show_bug.cgi?id=812860 The situation ought to be clarified, and some kind of solution found, as maintaining a custom slapd build just to be able to benefit from this extensability is largely overkill.

1 0

Re: (ITS#7274) delta-syncrepl MMR infinite loop
by quanah＠zimbra.com 29 May '12

29 May '12

--On Tuesday, May 29, 2012 6:25 PM -0700 Howard Chu <hyc(a)openldap.org> wrote: >> so it is tracking "000" as a third master? This seems to be why the >> original server (which was 000 before being promoted to 001) replicates >> these entries back to itself. > > The loop is caused by the patch to ITS#6872, which considers a consumer > out of date whenever the number of CSNs in its sync request doesn't match > the number known to the provider. > > The data here is basically invalid: server1 has entries generated using > SID=0 but it has no contextCSN value with SID=0. It only sent SID=1 and > SID=2 in its sync request. Server2, which just updated from server1, has > a contextCSN for SID=0 in addition to 1 and 2 (and that's all correct). > > Server1 should have always had a contextCSN value for SID=0 but doesn't. > This problem would not occur if server1 was converted first from > standalone into a single-master. I.e., load syncprov on it, let it scan > the DB and generate the first sid=0 contextCSN, before turning it intu a > MMR node. For documentation purposes -- The issue occurred because I set olcServerID before I loaded syncprov. Re-ordering my script to load syncprov (which then caused a contextCSN value to be correctly generated on Server1 for SID=0) fixed this loop. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7274) delta-syncrepl MMR infinite loop
by hyc＠OpenLDAP.org 29 May '12

29 May '12

quanah(a)zimbra.com wrote: > --On Wednesday, May 16, 2012 10:27 PM +0000 quanah(a)OpenLDAP.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.31 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.108.184.39) > > We can see that the script turning it into a master ran here: > > Thu May 17 16:05:46 2012 *** Running as zimbra user: > /opt/zimbra/libexec/zmldapenable-mmr -s 2 -m > ldap://zre-ldap002.eng.vmware.com:389/ > > so 16:05:46 > > In the accesslog, we see: > > dn: cn=accesslog > objectClass: auditContainer > cn: accesslog > structuralObjectClass: auditContainer > contextCSN: 20120517225152.913667Z#000000#000#000000 > contextCSN: 20120517230823.615364Z#000000#001#000000 > contextCSN: 20120517230546.409118Z#000000#002#000000 > > dn: reqStart=20120517230546.000019Z,cn=accesslog > objectClass: auditAdd > structuralObjectClass: auditAdd > reqStart: 20120517230546.000019Z > reqEnd: 20120517230546.000020Z > reqType: add > reqSession: 100 > reqAuthzID: cn=config > reqDN: cn=zimbra > reqResult: 0 > reqMod: objectClass:+ organizationalRole > reqMod: description:+ Zimbra Systems Application Data > reqMod: cn:+ zimbra > reqMod: structuralObjectClass:+ organizationalRole > reqMod: entryUUID:+ 40f78bea-34be-1031-8a5d-e1466f667e19 > reqMod: creatorsName:+ cn=config > reqMod: createTimestamp:+ 20120517224907Z > reqMod: entryCSN:+ 20120517224907.221672Z#000000#000#000000 > reqMod: modifiersName:+ cn=config > reqMod: modifyTimestamp:+ 20120517224907Z > reqEntryUUID: 40f78bea-34be-1031-8a5d-e1466f667e19 > entryUUID: 948929e2-34c0-1031-9a14-c93bd10ff0f2 > creatorsName: cn=config > createTimestamp: 20120517224907Z > entryCSN: 20120517224907.221672Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20120517224907Z > > so it is tracking "000" as a third master? This seems to be why the > original server (which was 000 before being promoted to 001) replicates > these entries back to itself. The loop is caused by the patch to ITS#6872, which considers a consumer out of date whenever the number of CSNs in its sync request doesn't match the number known to the provider. The data here is basically invalid: server1 has entries generated using SID=0 but it has no contextCSN value with SID=0. It only sent SID=1 and SID=2 in its sync request. Server2, which just updated from server1, has a contextCSN for SID=0 in addition to 1 and 2 (and that's all correct). Server1 should have always had a contextCSN value for SID=0 but doesn't. This problem would not occur if server1 was converted first from standalone into a single-master. I.e., load syncprov on it, let it scan the DB and generate the first sid=0 contextCSN, before turning it intu a MMR node. -- -- 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#7280) accesslog write to subentry of log database
by quanah＠zimbra.com 29 May '12

29 May '12

--On Sunday, May 27, 2012 11:27 PM +0000 openldap(a)stormcloud9.net wrote: > This is nonconstructive. I know not to do that, I'm the one who > filed the ITS...<br> > You don't address the feature request at all, only that it > currently doesn't work which is why the request was filed in the > first place. Is logging multiple accesslog overlays to the same > backend database unfeasible?<br> No. -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7282) Invalid Regex in Documentation
by quanah＠zimbra.com 29 May '12

29 May '12

--On Tuesday, May 29, 2012 5:04 PM +0000 alacer.cogitatus(a)gmail.com wrote: > Full_Name: Kyle Smith > Version: 2.4.30 > OS: Ubuntu Server 10.04.02LTS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.245.87.13) > > > In section 8.2.5 of the OpenLDAP Documentation (Access Control Examples), > the example regex to allow an IP address is given by: > > by peername.regex=IP:10\..+ read > > I think it should read: > > by peername.regex=IP=10\..+ read > > Thanks, fixed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

This is a cryptographically signed message in MIME format. --------------ms000604020701070406090000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > Michael Str=F6der wrote: >> hyc(a)symas.com wrote: >>> Michael Str=F6der wrote: >>>> Howard Chu wrote: >>>>> The text also states >>>>> The practice of storing hashed passwords in userPassword viol= ates >>>>> Standard Track (RFC 4519) schema specifications and may hinde= r >>>>> interoperability. >>>> >>>> In practice we all live very well with this for years. That's least = of a >>>> problem today. >>>> >>>>> Anyone building operational procedures on something that violates t= he specs >>>>> was asking for trouble. Users should be using ldappasswd, that's wh= at >>>>> it's for. >>>> >>>> ??? >>>> >>>> ldappasswd writes a hashed password to - tataa - attribute 'userPass= word'. >>>> I cannot see how this is different from using ldapadd/ldapmodify. >>> >>> Wrong, ldappasswd sends a PasswordModify exop to a server. The server= may >>> implement that exop in any implementation-specific manner, and there = is no >>> guarantee that the password a server uses is ever instantiated in any= LDAP >>> entry. There is no guarantee that setting a userPassword attribute us= ing >>> ldapadd/ldapmodify will ever do anything useful for any given LDAP us= er. >> >> You're arguing based on what a LDAP server could do. I'm arguing based= on what >> OpenLDAP and other server implementations are doing for years. >=20 > ActiveDirectory is an obvious example invalidating your argument. Does MS AD support RFC 3062? AFAIK W2K3 doesn't. I don't currently have the possibility to check with most recent W2K8R2 t= hough. Anyway that's not relevant here either. We're talking about how OpenLDAP stores and checks the passwords since over a decade. Violating Standard Track (RFC 4519) schema specifications could be avoide= d by implementing RFC 3112. But this also never happened. > Don't fix what isn't broken. With this argument you can immediately stop any progress. Maybe also a valuable statement by the OpenLDAP chief architect. Ciao, Michael. --------------ms000604020701070406090000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyOTIxMTU0N1owIwYJKoZIhvcNAQkEMRYE FPftjo2JfwDdzUByvPPFBJpEMBd4MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAqWLrqBEmQFwdUWzw3ZuQR0bnPzvAMZBb81cTmCzguvREDKdmO9vYvDVzoB/AhnnE6cE+ NYlO7uQBg7AiQSq++LoQ93tYsIjoZM44xiOxx8k+tAkhTUGEK4yJ9G86ptDRa/VSK25vC/Jg dfza7znhUF2210scAyjiG46RSRG/otIAhuMRjRKtvbC5jD5luJeJxePFpWR/V7+qKWmVvyJU mIGY90XdKmhY3b8XNWecfghap8V4NVNWzLuNxwH6vW8ym8+W4eZ/EsMsJ7+ht7HqgE71hjtj QtDfdcEGGww1Ch0tGj7HbynRm7pf2airOQ3j8GxMwFkkq/If8+4jqrNC1gAAAAAAAA== --------------ms000604020701070406090000--

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by quanah＠zimbra.com 29 May '12

29 May '12

--On Tuesday, May 29, 2012 8:38 PM +0000 michael(a)stroeder.com wrote: > Well, you're the OpenLDAP god. So you can arbitrarly decide whatever you > want. (But you shouldn't wonder why there's no active OpenLDAP community.) Comments like this weaken any point you are trying to make, serve no purpose, and are obnoxious. Your emails would be better served without them. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com 29 May '12

29 May '12

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Michael Ströder wrote: >>> Howard Chu wrote: >>>> The text also states >>>> The practice of storing hashed passwords in userPassword violates >>>> Standard Track (RFC 4519) schema specifications and may hinder >>>> interoperability. >>> >>> In practice we all live very well with this for years. That's least of a >>> problem today. >>> >>>> Anyone building operational procedures on something that violates the specs >>>> was asking for trouble. Users should be using ldappasswd, that's what it's for. >>> >>> ??? >>> >>> ldappasswd writes a hashed password to - tataa - attribute 'userPassword'. >>> I cannot see how this is different from using ldapadd/ldapmodify. >> >> Wrong, ldappasswd sends a PasswordModify exop to a server. The server may >> implement that exop in any implementation-specific manner, and there is no >> guarantee that the password a server uses is ever instantiated in any LDAP >> entry. There is no guarantee that setting a userPassword attribute using >> ldapadd/ldapmodify will ever do anything useful for any given LDAP user. > > You're arguing based on what a LDAP server could do. I'm arguing based on what > OpenLDAP and other server implementations are doing for years. ActiveDirectory is an obvious example invalidating your argument. > None of what you said in this thread is a real argument against adding SHA-2 > hash algos to the core. Still you did not answer why SHA-1 is in and SHA-2 is out. At present there is no need to change anything in the core since SHA-2 support can be dynamically loaded. Don't fix what isn't broken. -- -- 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#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

hyc(a)symas.com wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> The text also states >>> The practice of storing hashed passwords in userPassword violates >>> Standard Track (RFC 4519) schema specifications and may hinder >>> interoperability. >> >> In practice we all live very well with this for years. That's least of a >> problem today. >> >>> Anyone building operational procedures on something that violates the specs >>> was asking for trouble. Users should be using ldappasswd, that's what it's for. >> >> ??? >> >> ldappasswd writes a hashed password to - tataa - attribute 'userPassword'. >> I cannot see how this is different from using ldapadd/ldapmodify. > > Wrong, ldappasswd sends a PasswordModify exop to a server. The server may > implement that exop in any implementation-specific manner, and there is no > guarantee that the password a server uses is ever instantiated in any LDAP > entry. There is no guarantee that setting a userPassword attribute using > ldapadd/ldapmodify will ever do anything useful for any given LDAP user. You're arguing based on what a LDAP server could do. I'm arguing based on what OpenLDAP and other server implementations are doing for years. None of what you said in this thread is a real argument against adding SHA-2 hash algos to the core. Still you did not answer why SHA-1 is in and SHA-2 is out. Well, you're the OpenLDAP god. So you can arbitrarly decide whatever you want. (But you shouldn't wonder why there's no active OpenLDAP community.) Ciao, Michael.

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com 29 May '12

29 May '12

Michael Ströder wrote: > Howard Chu wrote: >> The text also states >> The practice of storing hashed passwords in userPassword violates >> Standard Track (RFC 4519) schema specifications and may hinder >> interoperability. > > In practice we all live very well with this for years. That's least of a > problem today. > >> Anyone building operational procedures on something that violates the specs >> was asking for trouble. Users should be using ldappasswd, that's what it's for. > > ??? > > ldappasswd writes a hashed password to - tataa - attribute 'userPassword'. > I cannot see how this is different from using ldapadd/ldapmodify. Wrong, ldappasswd sends a PasswordModify exop to a server. The server may implement that exop in any implementation-specific manner, and there is no guarantee that the password a server uses is ever instantiated in any LDAP entry. There is no guarantee that setting a userPassword attribute using ldapadd/ldapmodify will ever do anything useful for any given LDAP user. -- -- 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#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

This is a cryptographically signed message in MIME format. --------------ms050402080405010103060108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > The text also states > The practice of storing hashed passwords in userPassword violates > Standard Track (RFC 4519) schema specifications and may hinder > interoperability. In practice we all live very well with this for years. That's least of a problem today. > Anyone building operational procedures on something that violates the s= pecs > was asking for trouble. Users should be using ldappasswd, that's what i= t's for. ??? ldappasswd writes a hashed password to - tataa - attribute 'userPassword'= =2E I cannot see how this is different from using ldapadd/ldapmodify. So what are you really trying to say? Ciao, Michael. --------------ms050402080405010103060108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyOTE4MTEyMVowIwYJKoZIhvcNAQkEMRYE FMxpg47lo/Kju6s3IV/LCMAeyzViMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAPDeuZINq0dhCIixcpzDn15b8usj8fAjOx/IOUdH3GEfMwNcC7Qi4lEDwuT1hvriqLT9x RTO4CcPCm5GZ2A8MWqayf+oRZtfZmU6ueLNPS08D4fMIkdU5DScFGmSFajm/qVfP8V4iwWur xn4xtYjEXY6SqD2vZK0rYGrr9KS72pNunNEXzUkI6SmGVDp5Q9463FkoBQj9DFYrLSe5iBPO CVNZlHsnTfWvW3Cm4SP7x2VFoqpT6snisrYWv3hcJjSinsBCEnW+qwAcuCpuByMWA/hFr9vj OBz3Y1W7obMI6DUxdBq4ECdDWTDoqLsCfEJGLeoq1oQ9n5r2UNDSPnPJ9QAAAAAAAA== --------------ms050402080405010103060108--

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com 29 May '12

29 May '12

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Why should X user ever need to run this tool to generate a value? > >>From slappasswd(8): > > DESCRIPTION > Slappasswd is used to generate an userPassword value suitable > for use with ldapmodify(1), slapd.conf(5) rootpw configuration > directive or the slapd-config(5) olcRootPW configuration directive. > > Do you want to restrict this text regarding ldapmodify(1) only for the cases > that the slappasswd user has also write access to back-config? We could probably delete that ldapmodify(1) reference. Technically it has always been wrong, since there's never been any guarantee that an LDAP user's password was ever stored in any user-accessible attribute. > Of course your are the OpenLDAP boss. You can change everything to make it > work for you. But it breaks existing operational procedures for other people. The text also states The practice of storing hashed passwords in userPassword violates Standard Track (RFC 4519) schema specifications and may hinder interoperability. Anyone building operational procedures on something that violates the specs was asking for trouble. Users should be using ldappasswd, that's what it's for. -- -- 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-bugs