openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

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 05 Jun '12

05 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 05 Jun '12

05 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 05 Jun '12

05 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 31 May '12

31 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 31 May '12

31 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 31 May '12

31 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

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