openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#8449) slapadd - config file
by quanah＠openldap.org 23 Jun '16

23 Jun '16

--On Thursday, June 23, 2016 10:24 AM +0000 s.gopinath(a)nic.in wrote: > Full_Name: SGopinath > Version: 2.4.44 > OS: Debian 8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (164.100.167.137) > > > Dear Sir, > > I follow the steps provided in the Admin guide and doing source > installation. > > It compiles well and make install is okay. > > After that when I give > > usr/local/sbin/slapadd -F /usr/local/etc/config=cn -l > /r%r/local/etc/openldap/slapd.ldif > > It says... > 576baa27 invalid config directory /usr/local/etc/config=cn, error 2 > slapadd: bad configuration directory! Use /usr/local/etc/slapd.d. This is a typo that will be fixed with the next release. Generally the ITS system is for reporting bugs, not asking usage questions. In the future, please use openldap-technical(a)openldap.org for these types of questions. --Quanah -- Quanah Gibson-Mount Release and QA Engineer <http://www.openldap.org>

1 0

(ITS#8449) slapadd - config file
by s.gopinath＠nic.in 23 Jun '16

23 Jun '16

Full_Name: SGopinath Version: 2.4.44 OS: Debian 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (164.100.167.137) Dear Sir, I follow the steps provided in the Admin guide and doing source installation. It compiles well and make install is okay. After that when I give usr/local/sbin/slapadd -F /usr/local/etc/config=cn -l /r%r/local/etc/openldap/slapd.ldif It says... 576baa27 invalid config directory /usr/local/etc/config=cn, error 2 slapadd: bad configuration directory! Please help. Thanks, S.Gopinath

1 0

Re: (ITS#8447) LMDB: Overwriting values in MDB_DUPSORT databases broken
by h.b.furuseth＠usit.uio.no 22 Jun '16

22 Jun '16

On 21. juni 2016 01:35, hyc(a)symas.com wrote: > This is a misuse of MDB_CURRENT: as documented, the new value is supposed to > be the same size as the existing value. No, that's not what the doc says. "MDB_CURRENT - (...) intended to be used when the new data is the same size as the old. Otherwise it will simply perform a delete of the old record followed by an insert." I think LMDB should check the size, even if you change the doc to match the code rather than the other way around. If you want to avoid error checks, I'd rather avoid EINVAL checks like key==NULL which are easier for the user to check than "old size = new size". -- Hallvard

1 0

(ITS#8448) slapd aborted during replication
by quanah＠openldap.org 21 Jun '16

21 Jun '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44+ITS8432 OS: Linux 3.13 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) No symbol table info available. #4 0x00000000004ae6ba in slap_sl_malloc (size=140240355863183, ctx=0x0) at sl_malloc.c:310 sh = 0x0 ptr = 0xf4240 newptr = 0x0 __PRETTY_FUNCTION__ = "slap_sl_malloc" #5 0x00000000004582a2 in build_new_dn (new_dn=0x2190050, parent_dn=0x249b6c0, newrdn=0x7f8c3df35100, memctx=0x0) at dn.c:1154 ptr = 0x1640da00 "cn=accesslog" #6 0x00007f949e4f5bf1 in accesslog_entry (op=0x7f8c3df363f0, rs=0x7f8c3df35f70, logop=2, op2=0x7f8c3df352a0) at accesslog.c:1325 on = 0x22221e0 li = 0x2207de0 rdnbuf = "reqStart=20160620160747.1000000\000$R\363=\214\177" nrdnbuf = "reqStart=\000\266\236\224\177\000\000\000\000\000\000\000\000\000\000lR\363=\214\177\000\000\000 \230@\214\177" rdn = {bv_len = 31, bv_val = 0x7f8c3df35150 "reqStart=20160620160747.1000000"} nrdn = {bv_len = 140240355863169, bv_val = 0x7f8c3df35120 "reqStart="} timestamp = {bv_len = 22, bv_val = 0x7f8c3df35159 "20160620160747.1000000"} ntimestamp = {bv_len = 140240355863160, bv_val = 0x245a000 ""} bv = {bv_len = 140240311506032, bv_val = 0x7f8c3df35250 ""} lo = 0x7f949e6fcb10 e = 0x2190038 #7 0x00007f949e4f6614 in accesslog_response (op=0x7f8c3df363f0, rs=0x7f8c3df35f70) at accesslog.c:1528 on = 0x22221e0 li = 0x2207de0 a = 0x7f8c4098b010 last_attr = 0x8 m = 0x7f8c3df35488 b = 0x7f8c40958ff8 uuid = {bv_len = 36, bv_val = 0x10209c00 "28031e5e-38fb-1033-9eea-e5803fce8315"} i = 0 logop = 2 do_graduate = 0 lo = 0x7f949e6fcb10 e = 0x0 old = 0x0 e_uuid = 0x0 timebuf = "\300\340H\004\000\000\000\000\000\240E\002\000\000\000\000\240T\363=\214\177\000\000xf\267\000\000" bv = {bv_len = 64424509440, bv_val = 0x7f8c3df35520 "p_\363=\214\177"} ptr = 0x245a088 "" vals = 0x448e000 op2 = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = { rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = {rs_mods = { rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = { bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = { bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = { bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} rs2 = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, 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} #8 0x00000000004cd9b6 in over_back_response (op=0x7f8c3df363f0, rs=0x7f8c3df35f70) at backover.c:237 oi = 0x2222b40 on = 0x22221e0 rc = 32768 be = 0x7f8c3df35c30 db = {bd_info = 0x22221e0, bd_self = 0x20598e0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", 'C5C000' <repeats 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x249c500, be_nsuffix = 0x249c540, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x25409c0 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x25409e0 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x23bb960, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x3e86060, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x21b18c0, be_pb = 0x0, be_cf_ocs = 0x7f949ed7e120, be_private = 0x2772000, be_next = {stqe_next = 0x0}} #9 0x0000000000450522 in slap_response_play (op=0x7f8c3df363f0, rs=0x7f8c3df35f70) at result.c:537 sc_next = 0x7f8c3df35fe0 sc_nextp = 0x7f8c3df35c00 rc = 32768 sc = 0x5c680a8 scp = 0x5c680a8 #10 0x0000000000450747 in send_ldap_response (op=0x7f8c3df363f0, rs=0x7f8c3df35f70) at result.c:612 berbuf = { buffer = "\000\000\000\000\000\000\000\000\260\201\306\005\000\000\000\000\200Y\363=\214\177\000\000\360c\363=\214\177\000\000\n", '\000' <repeats 15 times>, "@\312\344\001\000\000\000\000\060\\\363=\214\177", '\000' <repeats 18 times>, "@X\363=\214\177\000\000\326P\264\236\224\177\000\000\252\004\230@\214\177\000\000\205\243\265\236\224\177\000\000\240X\363=\214\177\000\000\200X\363=\214\177\000\000\200Y\363=\214\177\000\000\360c\363=\214\177\000\000\000 w\002\000\000\000\000\000 w\002\000\000\000\000\005\000\000\000\000\000\000\000p\002", '\000' <repeats 14 times>"\323, \004\230@\214\177\000\000\f\003\230@\214\177\000\000\000\240E\002\000\000\000\000pX\363=\214\177\000\000\200\214\363?\214\177\000\000\300y\363=\214\177\000\000i\267W\242\224\177", '\000' <repeats 17 times>, ialign = 0, lalign = 0, falign = 0, dalign = 0, palign = 0x0} ber = 0x7f8c3df35770 rc = 0 bytes = 274615488 __PRETTY_FUNCTION__ = "send_ldap_response" #11 0x0000000000451691 in slap_send_ldap_result (op=0x7f8c3df363f0, rs=0x7f8c3df35f70) at result.c:891 tmp = 0x0 otext = 0x0 o oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #12 0x00007f949eb47abe in mdb_modify (op=0x7f8c3df363f0, rs=0x7f8c3df35f70) at modify.c:708 mdb = 0x2772000 e = 0x5c68160 manageDSAit = 2 textbuf = "\017\000\000\000\000\000\000\000\377\377\377\377\377\377\377\377\250\200\306\005\000\000\000\000\371\377\377\377\377\377\377\377\240Z\363=\214\177\000\000\200\214\363?\214\177\000\000\300y\363=\214\177\000\000\004\000\000\000\000\000\000\000\a\000\000\000\000\000\000\000%\rM\000\000\000\000\000\240Z\363=\214\177\000\000\070e\363=\214\177\000\000\003\000\000\000\000\000\000\000^\200\306\005\000\000\000\000Ѐ\306\005\000\000\000\000a\200\306\005\000\000\000\000^\200\306\005\000\000\000\000\001\000\000\000\001\000\000\000\250\200\306\005\000\000\000\000p_\363=\214\177\000\000p[\363=\214\177\000\000\371np\236\224\177\000\000p_\363=\214\177\000\000\360c\363=\214\177\000\000Ѐ\306\005\000\000\000\000\360c\363=\214\177\000\000Ȃ\306\005\000\000\000\000(d\363=\214\177\000\000p[\363=\214\177\000\000\374\200O\236\224\177\000\000p_\363=\214\177\000\000\360c\363=\214\177\000" textlen = 256 txn = 0x0 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x0}, moi_txn = 0x245a000, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7f8c3df359e0 dummy = {e_id = 0, e_name = {bv_len = 0, bv_val = 0xf8d2e98 ""}, e_nname = {bv_len = 0, bv_val = 0x5c68540 ""}, e_attrs = 0x975dfa0, e_ocflags = 82208, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x5c68160} preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x39e66a4fee, 0x7f8c3df35f70, 0x7f8c3df363f0, 0x7f8c3df35a45, 0x0} num_ctrls = 0 numads = 1324 #13 0x00000000004ce903 in overlay_op_walk (op=0x7f8c3df363f0, rs=0x7f8c3df35f70, which=op_modify, oi=0x2222b40, on=0x0) at backover.c:677 func = 0x7f949ed7e418 rc = 32768 #14 0x00000000004ceb30 in over_op_func (op=0x7f8c3df363f0, rs=0x7f8c3df35f70% w which=op_modify) at backover.c:730 oi = 0x2222b40 on = 0x2222960 be = 0x20598e0 db = {bd_info = 0x7f949ed7e3c0, bd_self = 0x20598e0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\101\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x249c500, be_nsuffix = 0x249c540, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x25409c0 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x25409e0 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x23bb960, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x3e86060, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x21b18c0, be_pb = 0x0, be_cf_ocs = 0x7f949ed7e120, be_private = 0x2772000, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7f8c3df35fe0, sc_response = 0x4cd8da <over_back_response>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x2222b40} sc = 0xfb532c0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #15 0x00000000004cec6c in over_op_modify (op=0x7f8c3df363f0, rs=0x7f8c3df35f70) at backover.c:769 No locals. #16 0x00000000004c157e in syncrepl_updateCookie (si=0x21b2ec0, op=0x7f8c3df363f0, syncCookie=0x7f8c3df36230) at syncrepl.c:3434 be = 0x20598e0 mod = {sml_mod = {sm_desc = 0x1e4ca40, sm_values = 0xf7686c0, sm_nvalues = 0x0, sm_numvals = 5, sm_op = 2, sm_flags = 1, sm_type = {bv_len = 10, bv_val = 0x1e35340 "contextCSN"}}, sml_next = 0x0}% first = {bv_len = 40, bv_val = 0x164ac690 "20160620160747.996249Z#000000#001#000000"} sc = {ctxcsn = 0xf7686c0, sids = 0x126ee0e0, numcsns = 5, rid = 0, octet_str = {bv_len = 0, bv_val = 0x0}, sid = 0, sc_next = {stqe_next = 0x0}} syn = 0x20359e0 rc = 0 i = 1 j = 1 changed = 1 len = 40 cb = {sc_next = 0x5c68078, sc_response = 0x4c3068 <null_callback>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x21b2ec0} rs_modify = {sr_type = REP_RESULT, sr_tag = 103, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, 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} __PRETTY_FUNCTION__ = "syncrepl_updateCookie" #17 0x00000000004b6f98 in do_syncrep2 (op=0x7f8c3df363f0, si=0x21b2ec0) at syncrepl.c:1017 match = 4443238 syncUUID = {{bv_len = 16, bv_val = 0x14772a87 "\340\061\242\332\313L\020\065\223\323S`\265\303zY"}, {bv_len = 18446744073709551615, bv_val = 0x7f8c3df36660 ""}} cookie = {bv_len = 60, bv_val = 0x14772a99 "rid=100,sid=001,csn=20160620160747.996249Z#000000#001#000000"} rctrls = 0xd97f0a0 rctrlp = 0x12070920 bdn = {bv_len = 44, bv_val = 0xf99c40a "reqStart=20160620160747.996073Z,cn=accesslog"} si_tag = 140240311511856 entntry = 0x39e698d440 punlock = 0 syncstate = 1 retdata = 0x10000 retoid = 0x0 syncUUIDs = 0xa000009af len = 60 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>"\200, *w\024\000\000\000\000\325*w\024\000\000\000\000\325*w\024", '\000' <repeats 28 times>, " c\363=\214\177\000\000\000\000\000\000\000\000\000\000\360b\363=\214\177\000\000\274\370\037S\377\177\000\000\360c\363=\214\177\000\000\226Zy\242\224\177\000\000\060c\363=\214\177\000\000\000\232u\000\000\000\000\000\060c\363=\214\177\000\000\341YE\000\000\000\000\000\bd\363=\214\177\000\000\000d\363=\214\177\000\000\323\024hW\000\000\000\000\226Zy\242\224\177\000\000\200c\363=\214\177\000\000Ⱥ\332\n\000\000\000\000\300c\363=\214\177\000\000\366\254{\242\224\177\000\000\360c\363=\214\177\000\000\354c\363=\214\177\000\000\220c\363=\001\000\000\000@\200\261\n\000\000\000", ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = 0x7f8c3df36270 msg = 0x12930680 syncCookie = {ctxcsn = 0x129f7660, sids = 0x1383c138, numcsns = 1, rid = 100, octet_str = {bv_len = 60, bv_val = 0x12551a80 "rid=100,sid=001,csn=20160620160747.996249Z#000000#001#000000"}, sid = 1, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x14146ae0, sids = 0x12c7ca00, numcsns = 5, rid = 100, octet_str = {bv_len = 0, bv_val = 0x0}, sid = 3, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 32652 tout_p = 0x7f8c3df361c0 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" __PRETTY_FUNCTION__ = "do_syncrep2" #18 0x00000000004b9107 in do_syncrepl (ctx=0x7f8c3df36b30, arg=0x1e3ddb0) at syncrepl.c:1565 rtask = 0x1e3ddb0 si = 0x21b2ec0 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4f30b0 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f30b0 ""}, c_listener = 0x4fb160, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x45127c <slap_send_ldap_result>, c_send_search_entry = 0x452160 <slap_send_search_entry>, c_send_search_reference = 0x454210 <slap_send_search_reference>, c_send_ldap_extended = 0x451c22 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x451f3d <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7f8c3df36560, o_tag = 102, o_time = 1466438867, o_tincr = 1000000, o_bd = 0x7f8c3df35530, o_req_dn = {bv_len = 0, bv_val = 0x1e2d050 ""}, o_req_ndn = { bv_len =%2, bv_val = 0x1e2d050 ""}, o_request = {oq_add = {rs_modlist = 0x7f8c3df36060, rs_e = 0x1}, oq_bind = {rb_method = 1039360096, rb_cred = {bv_len = 1, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = Bbv_v_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x7f8c3df36060}, oq_modify = {rs_mods = { rs_modlist = 0x7f8c3df36060, rs_no_opattrs = 1 '\001'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x7f8c3df36060, rs_no_opattrs = 1 '\001'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = { rs_scope = 1039360096, rs_deref = 32652, rs_slitit = 1, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 1039360096}, oq_cancel = {rs_msgid = 1039360096}, oq_extended = {rs_reqoid % % {bv_len = 140240311509088, bv_val = 0x1 <Address 0x1 out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 140240311509088, bv_val = 0x1 <Address 0x1 out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 1 '\001', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\002", '\000' <repeats 16 time3E3E, o_controls = 0x7f8c3df366a8, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x25409c0 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x25409e0 "cn=config"}, sai_ssf =%2, sai_tranorort_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7f8c3df35c00, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x5c68040 "20160620160747.996249Z#000000#001#000000"}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 100, oh_conn = 0x7f8c3df367b0, oh_msgid = 0, oh_protocol = 0, oh_tid = 140240311514880, oh_threadctx = 0x7f8c3df36b30, oh_tmpmemctx = 0x44ad780, oh_tmpmfuncs = 0x757a40, oh_counters = 0x75af80, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 17 times>, 0x7f8c3df36230, 0x0 <repeats 14 times>}} op = 0x7f8c3df363f0 rc = 0 dostop = 0 s = 113 i = 0 defer = 1 fail = 0 freeinfo = 0 be = 0x20598e0 #19 0x000000000043adb9 in connection_read_thread (ctx=0x7f8c3df36b30, argv=0x71) at connection.c:1273 rc = 0 cri = {op = 0x0, func = 0x4b8bdf <do_syncrepl>, arg = 0x1e3ddb0, ctx = 0x7f8c3df36b30, nullop = 0} s = 113 #20 0x00007f94a2794332 in ldap_int_thread_pool_wrapper (xpool=0x1e64000) at tpool.c:956 pq = 0x1e64000 pool = 0x2028240 task = 0x44ab020 work_list = 0x1e64070 ctx = {ltu_pq = 0x1e64000, ltu_id = 140240311514880, ltu_key = {{ltk_key = 0x43a347, ltk_data = 0x2033b00, ltk_free = 0x43a18b <conn_counter_destroy>}, {ltk_key = 0x4ae1c7, ltk_data = 0x44ad780, ltk_free = 0x4adfec <slap_sl_mem_destroy>}, {ltk_key = 0x4555e5, ltk_data = 0x14317680, ltk_free = 0x455538 <slap_op_q_destroy>}, {ltk_key = 0x2030d00, ltk_data = 0x47c8800, ltk_free = 0x7f949eb59723 <mdb_reader_free>}, {ltk_key = 0x7f949eb4e554, ltk_data = 0x745a000, ltk_free = 0x7f949eb4e531 <search_stack_free>}, { ltk_key = 0x7f949eb4b011, ltk_data = 0x715a000, ltk_free = 0x7f949eb4afc9 <scope_chunk_free>}, {ltk_key = 0x2031400, ltk_data = 0x5e09400, ltk_free = 0x7f949eb59723 <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x12f37200, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 786 hash = 3996113682 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #21 0x00000039e6a079d1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #22 0x00000039e66e88fd in clone () from /lib64/libc.so.6 No symbol table info available.

1 0

Re: (ITS#8445) LibreSSL v2.4 compile
by cpaynetaffe＠gmail.com 21 Jun '16

21 Jun '16

--001a113faca2cd5c170535ccd806 Content-Type: text/plain; charset=UTF-8 This is LibreSSL's response. ---------- Forwarded message --------- From: Bob Beck <beck(a)obtuse.com> Date: Tue, Jun 21, 2016 at 11:45 AM Subject: Re: OpenSSL v1.1 API To: Connor Taffe <cpaynetaffe(a)gmail.com> Cc: <libressl(a)openbsd.org> I would say we would plan on it "when we need it" - We will support TLS 1.3 as it stabilizes, but at this stage I couldn't say when/if particular OpenSSL'isms might be supported. BoringSSL hasn't pulled in X509_NAME_get0_der either yet - so I think we will be taking what I would describe as a cautious and selective approach to new features from OpenSSL - During the same time as we've moved from about 750,000 of code at the fork to about 350,000 - OpenSSL is now over 1,000,000 lines - So we're probably not going to be about wholesale code importing from OpenSSL - We will be taking things selectively and with a degree of caution. Of note - we *do* support a newer API - libtls - which may be more than fine for most of OpenLDAP's needs: See http://man.openbsd.org/OpenBSD-current/man3/tls_init.3 and/or http://www.openbsd.org/papers/libtls-fsec-2015/ On Mon, Jun 20, 2016 at 09:21:43AM +0000, Connor Taffe wrote: > Hey, > > Does LibreSSL plan to implement the OpenSSL v1.1 API? > > I've submitted a patch to OpenLDAP to allow compilation with LibreSSL > v2.4.1. The patch currently checks if LIBRESSL_VERSION_NUMBER is defined > and if so uses the fallback code for versions of OpenSSL < 1.1. > > The maintainers would like to cap the version on the LibreSSL check if > implementation of the OpenSSL v1.1 API is planned. > > Specifically (to this case) OpenSSL added the SSL_CTX_up_ref function in > commit c5ebfcab713a82a1d46a51c8c2668c419425b387 in March of this year, and > added X509_NAME_get0_der in commit 7ab507495b86371756575d606af556b4fd74e27a > in January of this year. > > ---------- Forwarded message --------- > From: Howard Chu <hyc(a)symas.com> > Date: Mon, Jun 20, 2016 at 1:38 AM > Subject: Re: (ITS#8445) LibreSSL v2.4 compile > To: Connor Taffe <cpaynetaffe(a)gmail.com>, <openldap-its(a)openldap.org> > > > Connor Taffe wrote: > > Fixed, attached is a patch. > > I'm a bit concerned that you're only checking for the existence of LIBRESSL > instead of actually comparing the version number. Since the OpenSSL change > is > based on their v1.1 API, do you know if/when LibreSSL plans to adopt the > new API? > > > On Sun, Jun 19, 2016 at 8:02 PM Howard Chu <hyc(a)symas.com > > <mailto:hyc@symas.com>> wrote: > > > > cpaynetaffe(a)gmail.com <mailto:cpaynetaffe@gmail.com> wrote: > > > Full_Name: Connor Taffe > > > Version: master > > > OS: Ubuntu devel > > > URL: ftp://ftp.openldap.org/incoming/ > > > Submission from: (NULL) (50.25.160.41) > > > > > > > > > Compiling against LibreSSL v2.4.1 failed linking with > SSL_CTX_up_ref and > > > X509_NAME_get0_der undefined. I added checking if > > LIBRESSL_VERSION_NUMBER to the > > > same conditional compilation ifs that are defined for old versions > of > > OpenSSL. > > > > > > https://github.com/cptaffe/openldap > > > > Please read the Developer Guidelines. I'm not going to pull an > arbitrary repo > > to find someone's patch. > > > > http://www.openldap.org/devel/contributing.html > > > > -- > > -- Howard Chu > > CTO, Symas Corp. http://www.symas.com > > Director, Highland Sun http://highlandsun.com/hyc/ > > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ --001a113faca2cd5c170535ccd806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">This is LibreSSL's response. <div class=3D"gmai= l_quote"><div dir=3D"ltr">---------- Forwarded message --------- From: B= ob Beck <<a href=3D"mailto:beck@obtuse.com">beck(a)obtuse.com</a>> D= ate: Tue, Jun 21, 2016 at 11:45 AM Subject: Re: OpenSSL v1.1 API To: = Connor Taffe <<a href=3D"mailto:cpaynetaffe@gmail.com">cpaynetaffe@gmail= .com</a>> Cc: <<a href=3D"mailto:libressl@openbsd.org">libressl@o= penbsd.org</a>> </div> I would say we would plan on it=C2=A0 "when we need it" - We will= support TLS 1.3 as it stabilizes, but at this stage I couldn't say when/if particular Open= SSL'isms might be supported. BoringSSL hasn't pulled in X509_NAME_get0_der either yet - so I think w= e will be taking what I would describe as a cautious and selective approach to new features from OpenSSL - During the same time as we've moved from ab= out 750,000 of code at the fork to about 350,000 - OpenSSL is now over 1,000,00= 0 lines - So we're probably not going to be about wholesale code importin= g from OpenSSL - We will be taking things selectively and with a degree of caution. Of note - we *do* support a newer API - libtls - which may be more than fine for most of OpenLDAP's needs: See <a href=3D"http://man.openbsd.org/OpenBSD-current/man3/tls_init.3" rel=3D"n= oreferrer" target=3D"_blank">http://man.openbsd.org/OpenBSD-current/man3/tl= s_init.3</a> and/or <a href=3D"http://www.openbsd.org/papers/libtls-fsec-2015/" rel=3D"noreferr= er" target=3D"_blank">http://www.openbsd.org/papers/libtls-fsec-2015/</a><b= r> On Mon, Jun 20, 2016 at 09:21:43AM +0000, Connor Taffe wrote: > Hey, > > Does LibreSSL plan to implement the OpenSSL v1.1 API? > > I've submitted a patch to OpenLDAP to allow compilation with Libre= SSL > v2.4.1. The patch currently checks if LIBRESSL_VERSION_NUMBER is defin= ed > and if so uses the fallback code for versions of OpenSSL < 1.1. > > The maintainers would like to cap the version on the LibreSSL check if= > implementation of the OpenSSL v1.1 API is planned. > > Specifically (to this case) OpenSSL added the SSL_CTX_up_ref function = in > commit c5ebfcab713a82a1d46a51c8c2668c419425b387 in March of this year,= and > added X509_NAME_get0_der in commit 7ab507495b86371756575d606af556b4fd7= 4e27a > in January of this year. > > ---------- Forwarded message --------- > From: Howard Chu <<a href=3D"mailto:hyc@symas.com" target=3D"_blank= ">hyc(a)symas.com</a>> > Date: Mon, Jun 20, 2016 at 1:38 AM > Subject: Re: (ITS#8445) LibreSSL v2.4 compile > To: Connor Taffe <<a href=3D"mailto:cpaynetaffe@gmail.com" target= =3D"_blank">cpaynetaffe(a)gmail.com</a>>, <<a href=3D"mailto:openldap-i= ts(a)openldap.org" target=3D"_blank">openldap-its(a)openldap.org</a>> > > > Connor Taffe wrote: > > Fixed, attached is a patch. > > I'm a bit concerned that you're only checking for the existenc= e of LIBRESSL > instead of actually comparing the version number. Since the OpenSSL ch= ange > is > based on their v1.1 API, do you know if/when LibreSSL plans to adopt t= he > new API? > > > On Sun, Jun 19, 2016 at 8:02 PM Howard Chu <<a href=3D"mailto:= hyc(a)symas.com" target=3D"_blank">hyc(a)symas.com</a> > > <mailto:<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc= @symas.com</a>>> wrote: > > > >=C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:cpaynetaffe@gmail.com" targe= t=3D"_blank">cpaynetaffe(a)gmail.com</a> <mailto:<a href=3D"mailto:cpaynet= affe(a)gmail.com" target=3D"_blank">cpaynetaffe(a)gmail.com</a>> wrote: > >=C2=A0 =C2=A0 =C2=A0 > Full_Name: Connor Taffe > >=C2=A0 =C2=A0 =C2=A0 > Version: master > >=C2=A0 =C2=A0 =C2=A0 > OS: Ubuntu devel > >=C2=A0 =C2=A0 =C2=A0 > URL: <a href=3D"ftp://ftp.openldap.org/i= ncoming/" rel=3D"noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incom= ing/</a> > >=C2=A0 =C2=A0 =C2=A0 > Submission from: (NULL) (50.25.160.41)<b= r> > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0 > Compiling against LibreSSL v2.4.1 failed= linking with > SSL_CTX_up_ref and > >=C2=A0 =C2=A0 =C2=A0 > X509_NAME_get0_der undefined. I added ch= ecking if > >=C2=A0 =C2=A0 =C2=A0LIBRESSL_VERSION_NUMBER to the > >=C2=A0 =C2=A0 =C2=A0 > same conditional compilation ifs that ar= e defined for old versions > of > >=C2=A0 =C2=A0 =C2=A0OpenSSL. > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0 > <a href=3D"https://github.com/cptaffe/op= enldap" rel=3D"noreferrer" target=3D"_blank">https://github.com/cptaffe/ope= nldap</a> > > > >=C2=A0 =C2=A0 =C2=A0Please read the Developer Guidelines. I'm = not going to pull an > arbitrary repo > >=C2=A0 =C2=A0 =C2=A0to find someone's patch. > > > >=C2=A0 =C2=A0 =C2=A0<a href=3D"http://www.openldap.org/devel/contr= ibuting.html" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/= devel/contributing.html</a> > > > >=C2=A0 =C2=A0 =C2=A0-- > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Howard Chu > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CTO, Symas Corp. <a href=3D"http= ://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas.com= </a> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Director, Highland Sun <a href= =3D"http://highlandsun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http:= //highlandsun.com/hyc/</a> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Chief Architect, OpenLDAP <a hre= f=3D"http://www.openldap.org/project/" rel=3D"noreferrer" target=3D"_blank"= >http://www.openldap.org/project/</a> > > > > > -- >=C2=A0 =C2=A0 -- Howard Chu >=C2=A0 =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= <a href=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http:= //www.symas.com</a> >=C2=A0 =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http= ://highlandsun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highla= ndsun.com/hyc/</a> >=C2=A0 =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.ope= nldap.org/project/" rel=3D"noreferrer" target=3D"_blank">http://www.openlda= p.org/project/</a> </div></div> --001a113faca2cd5c170535ccd806--

1 0

Re: (ITS#8447) LMDB: Overwriting values in MDB_DUPSORT databases broken
by hyc＠symas.com 21 Jun '16

21 Jun '16

lukaswhl(a)gmail.com wrote: > Full_Name: Lukas W > Version: mdb.master c367c1f69685a4d307acb8cea6945c1d67e1cc7e > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (114.23.231.86) > > > Replacing values in sub-databases (with MDB_DUPSORT) can lead to the new data's > length being ignored. This specific example reproduces the problem (creating the > entries "1"->"ABC", and "1"->2a2abc"): > > […] > mdb_dbi_open(txn, NULL, MDB_DUPSORT, &dbi); > key.mv_size = 2; > key.mv_data = "1"; > data.mv_size = 4; > data.mv_data = "ABC"; > mdb_put(txn, dbi, &key, &data, 0); > data.mv_data = "abc"; > mdb_put(txn, dbi, &key, &data, 0); > > If one later tries to change a value of one of the existing entries, the new > value is being copied, but the size is not changed. This could lead to database > corruption if the new value is longer than the old one as the length of the new > value is used in memcpy. > > key.mv_ze % = 2; > key.mv_data = "1"; > data.mv_size = 4; > data.mv_data = "abc"; > mdb_cursor_get(cursor, &key, &data, MDB_GET_BOTH); > > data.mv_size = 2; > data.mv_data = "Q"; > mdb_cursor_put(cursor, &key, &data, MDB_CURRENT); This is a misuse of MDB_CURRENT: as documented, the new value is supposed to be the same size as the existing value. > > mdb_cursor_get(cursor, &key, &data, MDB_GET_CURRENT); > printf("%s (%d)\n", data.mv_size); > > This will output "Q (4)", while it should output "Q (2)". Note that the data in > the DB probably is "Q\0c", printf just stops at the null character. > The value is written in mdb.c:7516. Context: > > […] > /* same size, just replace it. Note that we could > * also reuse this node if the new data is smaller, > * but instead we opt to shrink the node in that case. > */ > if (F_ISSET(flags, MDB_RESERVE)) > data->mv_data = olddata.mv_data; > else if (!(mc->mc_flags & C_SUB)) > memcpy(olddata.mv_data, data->mv_data, data->mv_size); > else { > 7516: memcpy(NODEKEY(leaf), key->mv_data, key->mv_size); > goto fix_parent; > } > […] > > > -- -- 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#8447) LMDB: Overwriting values in MDB_DUPSORT databases broken
by lukaswhl＠gmail.com 21 Jun '16

21 Jun '16

Full_Name: Lukas W Version: mdb.master c367c1f69685a4d307acb8cea6945c1d67e1cc7e OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (114.23.231.86) Replacing values in sub-databases (with MDB_DUPSORT) can lead to the new data's length being ignored. This specific example reproduces the problem (creating the entries "1"->"ABC", and "1"->2a2abc"): [] mdb_dbi_open(txn, NULL, MDB_DUPSORT, &dbi); key.mv_size = 2; key.mv_data = "1"; data.mv_size = 4; data.mv_data = "ABC"; mdb_put(txn, dbi, &key, &data, 0); data.mv_data = "abc"; mdb_put(txn, dbi, &key, &data, 0); If one later tries to change a value of one of the existing entries, the new value is being copied, but the size is not changed. This could lead to database corruption if the new value is longer than the old one as the length of the new value is used in memcpy. key.mv_ze % = 2; key.mv_data = "1"; data.mv_size = 4; data.mv_data = "abc"; mdb_cursor_get(cursor, &key, &data, MDB_GET_BOTH); data.mv_size = 2; data.mv_data = "Q"; mdb_cursor_put(cursor, &key, &data, MDB_CURRENT); mdb_cursor_get(cursor, &key, &data, MDB_GET_CURRENT); printf("%s (%d)\n", data.mv_size); This will output "Q (4)", while it should output "Q (2)". Note that the data in the DB probably is "Q\0c", printf just stops at the null character. The value is written in mdb.c:7516. Context: [] /* same size, just replace it. Note that we could * also reuse this node if the new data is smaller, * but instead we opt to shrink the node in that case. */ if (F_ISSET(flags, MDB_RESERVE)) data->mv_data = olddata.mv_data; else if (!(mc->mc_flags & C_SUB)) memcpy(olddata.mv_data, data->mv_data, data->mv_size); else { 7516: memcpy(NODEKEY(leaf), key->mv_data, key->mv_size); goto fix_parent; } []

1 0

Re: (ITS#8445) LibreSSL v2.4 compile
by cpaynetaffe＠gmail.com 20 Jun '16

20 Jun '16

--001a113eeb0accaf2b0535b8d348 Content-Type: text/plain; charset=UTF-8 Unfortunately LibreSSL defines OPENSSL_VERSION_NUBMER as 0x02000000. On Mon, Jun 20, 2016 at 11:40 AM Howard Chu <hyc(a)symas.com> wrote: > Connor Taffe wrote: > > Good point, > > > > I was assuming that LibreSSL was focused on only maintaining > compatibility > > with v1.0.1 though, as they've created their own libtls for future > programs. > > > > Git grep didn't show anything in the v2.4.1 portable repo. > > The v1.1 API is still in pre-release it looks like, and the relevant > functions > > have > > only been in OpenSSL since January and March respectively according to > git. > > In fact LibreSSL has had only a handful of commits this year in portable, > > mostly focused on building with cmake and some fixes, but no API > additions. > > > > Neither function is available in the -current OpenBSD cvs tree either. > > > > I've emailed libressl(a)openbsd.org <mailto:libressl@openbsd.org> to > inquire > > further. > > Thanks. In the meantime I think the sane thing to do is just invert the > current #if. Swap the code so it's > > #if OPENSSL_VERSION_NUMBER >= 0x01010000 > new stuff > #else > old stuff > #endif > > then we can ignore this until LibreSSL catches up. > > > > On Mon, Jun 20, 2016 at 1:38 AM Howard Chu <hyc(a)symas.com > > <mailto:hyc@symas.com>> wrote: > > > > Connor Taffe wrote: > > > Fixed, attached is a patch. > > > > I'm a bit concerned that you're only checking for the existence of > LIBRESSL > > instead of actually comparing the version number. Since the OpenSSL > change is > > based on their v1.1 API, do you know if/when LibreSSL plans to adopt > the > > new API? > > > > > On Sun, Jun 19, 2016 at 8:02 PM Howard Chu <hyc(a)symas.com > > <mailto:hyc@symas.com> > > > <mailto:hyc@symas.com <mailto:hyc@symas.com>>> wrote: > > > > > > cpaynetaffe(a)gmail.com <mailto:cpaynetaffe@gmail.com> > > <mailto:cpaynetaffe@gmail.com <mailto:cpaynetaffe@gmail.com>> wrote: > > > > Full_Name: Connor Taffe > > > > Version: master > > > > OS: Ubuntu devel > > > > URL: ftp://ftp.openldap.org/incoming/ > > > > Submission from: (NULL) (50.25.160.41) > > > > > > > > > > > > Compiling against LibreSSL v2.4.1 failed linking with > > SSL_CTX_up_ref and > > > > X509_NAME_get0_der undefined. I added checking if > > > LIBRESSL_VERSION_NUMBER to the > > > > same conditional compilation ifs that are defined for old > > versions of > > > OpenSSL. > > > > > > > > https://github.com/cptaffe/openldap > > > > > > Please read the Developer Guidelines. I'm not going to pull an > > arbitrary repo > > > to find someone's patch. > > > > > > http://www.openldap.org/devel/contributing.html > > > > > > -- > > > -- Howard Chu > > > CTO, Symas Corp. http://www.symas.com > > > Director, Highland Sun http://highlandsun.com/hyc/ > > > Chief Architect, OpenLDAP > http://www.openldap.org/project/ > > > > > > > > > -- > > -- Howard Chu > > CTO, Symas Corp. http://www.symas.com > > Director, Highland Sun http://highlandsun.com/hyc/ > > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a113eeb0accaf2b0535b8d348 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Unfortunately LibreSSL defines OPENSSL_VERSION_NUBMER= as=C2=A00x02000000.</div></div> <div cl= ass=3D"gmail_quote"><div dir=3D"ltr">On Mon, Jun 20, 2016 at 11:40 AM Howar= d Chu <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote: = </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex">Connor Taffe wrote: > Good point, > >=C2=A0 =C2=A0I was assuming that LibreSSL was focused on only maintaini= ng compatibility > with v1.0.1 though, as they've created their own libtls for future= programs. > > Git grep didn't show anything in the v2.4.1 portable repo. > The v1.1 API is still in pre-release it looks like, and the relevant f= unctions > have > only been in OpenSSL since January and March respectively according to= git. > In fact LibreSSL has had only a handful of commits this year in portab= le, > mostly focused on building with cmake and some fixes, but no API addit= ions. > > Neither function is available in the -current OpenBSD cvs tree either.= > > I've emailed <a href=3D"mailto:libressl@openbsd.org" target=3D"_bl= ank">libressl(a)openbsd.org</a> <mailto:<a href=3D"mailto:libressl@openbsd= .org" target=3D"_blank">libressl(a)openbsd.org</a>> to inquire > further. Thanks. In the meantime I think the sane thing to do is just invert the current #if. Swap the code so it's #if OPENSSL_VERSION_NUMBER >=3D 0x01010000 =C2=A0 =C2=A0new stuff #else =C2=A0 =C2=A0old stuff #endif then we can ignore this until LibreSSL catches up. > > On Mon, Jun 20, 2016 at 1:38 AM Howard Chu <<a href=3D"mailto:hyc@s= ymas.com" target=3D"_blank">hyc(a)symas.com</a> > <mailto:<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc@syma= s.com</a>>> wrote: > >=C2=A0 =C2=A0 =C2=A0Connor Taffe wrote: >=C2=A0 =C2=A0 =C2=A0 > Fixed, attached is a patch. > >=C2=A0 =C2=A0 =C2=A0I'm a bit concerned that you're only checki= ng for the existence of LIBRESSL >=C2=A0 =C2=A0 =C2=A0instead of actually comparing the version number. S= ince the OpenSSL change is >=C2=A0 =C2=A0 =C2=A0based on their v1.1 API, do you know if/when LibreS= SL plans to adopt the >=C2=A0 =C2=A0 =C2=A0new API? > >=C2=A0 =C2=A0 =C2=A0 > On Sun, Jun 19, 2016 at 8:02 PM Howard Chu &l= t;<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a> >=C2=A0 =C2=A0 =C2=A0<mailto:<a href=3D"mailto:hyc@symas.com" target= =3D"_blank">hyc(a)symas.com</a>> >=C2=A0 =C2=A0 =C2=A0 > <mailto:<a href=3D"mailto:hyc@symas.com" t= arget=3D"_blank">hyc(a)symas.com</a> <mailto:<a href=3D"mailto:hyc@symas.c= om" target=3D"_blank">hyc(a)symas.com</a>>>> wrote: >=C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 > <a href=3D"mailto:cpaynetaffe@gmail.com" targ= et=3D"_blank">cpaynetaffe(a)gmail.com</a> <mailto:<a href=3D"mailto:cpayne= taffe(a)gmail.com" target=3D"_blank">cpaynetaffe(a)gmail.com</a>> >=C2=A0 =C2=A0 =C2=A0<mailto:<a href=3D"mailto:cpaynetaffe@gmail.com"= target=3D"_blank">cpaynetaffe(a)gmail.com</a> <mailto:<a href=3D"mailto:c= paynetaffe(a)gmail.com" target=3D"_blank">cpaynetaffe(a)gmail.com</a>>> w= rote: >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Full_Name: Connor Ta= ffe >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Version: master >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > OS: Ubuntu devel >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > URL: <a href=3D"ftp:= //ftp.openldap.org/incoming/" rel=3D"noreferrer" target=3D"_blank">ftp://ft= p.openldap.org/incoming/</a> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Submission from: (NU= LL) (50.25.160.41) >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Compiling against Li= breSSL v2.4.1 failed linking with >=C2=A0 =C2=A0 =C2=A0SSL_CTX_up_ref and >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > X509_NAME_get0_der u= ndefined. I added checking if >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0LIBRESSL_VERSION_NUMBER to= the >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > same conditional com= pilation ifs that are defined for old >=C2=A0 =C2=A0 =C2=A0versions of >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0OpenSSL. >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <a href=3D"https://g= ithub.com/cptaffe/openldap" rel=3D"noreferrer" target=3D"_blank">https://gi= thub.com/cptaffe/openldap</a> >=C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Please read the Developer = Guidelines. I'm not going to pull an >=C2=A0 =C2=A0 =C2=A0arbitrary repo >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to find someone's patc= h. >=C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 > <a href=3D"http://www.openldap.org/devel/cont= ributing.html" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org= /devel/contributing.html</a> >=C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0-- >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Howard Ch= u >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CTO, Symas C= orp. <a href=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">= http://www.symas.com</a> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Director, Hi= ghland Sun <a href=3D"http://highlandsun.com/hyc/" rel=3D"noreferrer" targe= t=3D"_blank">http://highlandsun.com/hyc/</a> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Chief Archit= ect, OpenLDAP <a href=3D"http://www.openldap.org/project/" rel=3D"noreferre= r" target=3D"_blank">http://www.openldap.org/project/</a> >=C2=A0 =C2=A0 =C2=A0 > > > >=C2=A0 =C2=A0 =C2=A0-- >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Howard Chu >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CTO, Symas Corp. <a href=3D"http://ww= w.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas.com</a><= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Director, Highland Sun <a href=3D"htt= p://highlandsun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highl= andsun.com/hyc/</a> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Chief Architect, OpenLDAP <a href=3D"= http://www.openldap.org/project/" rel=3D"noreferrer" target=3D"_blank">http= ://www.openldap.org/project/</a> > -- =C2=A0 =C2=A0-- Howard Chu =C2=A0 =C2=A0CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a hr= ef=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www= .symas.com</a> =C2=A0 =C2=A0Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://hi= ghlandsun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun= .com/hyc/</a> =C2=A0 =C2=A0Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap= .org/project/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org= /project/</a> </blockquote></div> --001a113eeb0accaf2b0535b8d348--

1 0

Re: (ITS#8445) LibreSSL v2.4 compile
by hyc＠symas.com 20 Jun '16

20 Jun '16

Connor Taffe wrote: > Good point, > > I was assuming that LibreSSL was focused on only maintaining compatibility > with v1.0.1 though, as they've created their own libtls for future programs. > > Git grep didn't show anything in the v2.4.1 portable repo. > The v1.1 API is still in pre-release it looks like, and the relevant functions > have > only been in OpenSSL since January and March respectively according to git. > In fact LibreSSL has had only a handful of commits this year in portable, > mostly focused on building with cmake and some fixes, but no API additions. > > Neither function is available in the -current OpenBSD cvs tree either. > > I've emailed libressl(a)openbsd.org <mailto:libressl@openbsd.org> to inquire > further. Thanks. In the meantime I think the sane thing to do is just invert the current #if. Swap the code so it's #if OPENSSL_VERSION_NUMBER >= 0x01010000 new stuff #else old stuff #endif then we can ignore this until LibreSSL catches up. > > On Mon, Jun 20, 2016 at 1:38 AM Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > Connor Taffe wrote: > > Fixed, attached is a patch. > > I'm a bit concerned that you're only checking for the existence of LIBRESSL > instead of actually comparing the version number. Since the OpenSSL change is > based on their v1.1 API, do you know if/when LibreSSL plans to adopt the > new API? > > > On Sun, Jun 19, 2016 at 8:02 PM Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com> > > <mailto:hyc@symas.com <mailto:hyc@symas.com>>> wrote: > > > > cpaynetaffe(a)gmail.com <mailto:cpaynetaffe@gmail.com> > <mailto:cpaynetaffe@gmail.com <mailto:cpaynetaffe@gmail.com>> wrote: > > > Full_Name: Connor Taffe > > > Version: master > > > OS: Ubuntu devel > > > URL: ftp://ftp.openldap.org/incoming/ > > > Submission from: (NULL) (50.25.160.41) > > > > > > > > > Compiling against LibreSSL v2.4.1 failed linking with > SSL_CTX_up_ref and > > > X509_NAME_get0_der undefined. I added checking if > > LIBRESSL_VERSION_NUMBER to the > > > same conditional compilation ifs that are defined for old > versions of > > OpenSSL. > > > > > > https://github.com/cptaffe/openldap > > > > Please read the Developer Guidelines. I'm not going to pull an > arbitrary repo > > to find someone's patch. > > > > http://www.openldap.org/devel/contributing.html > > > > -- > > -- Howard Chu > > CTO, Symas Corp. http://www.symas.com > > Director, Highland Sun http://highlandsun.com/hyc/ > > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- -- 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#8446) Various bug fixes for the async-meta backend
by nivanova＠symas.com 20 Jun '16

20 Jun '16

Full_Name: Nadezhda Ivanova Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160620_1.patch Submission from: (NULL) (78.83.54.234) Some new bug fixes for the async-meta backend 1. Removed some unused attributes from olcAsyncMetaConfig. These attributes were removed when some configuration options were removed for asyncmeta, being no longer applicable, but removing them from the class definition was missed. ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160620_1.patch 2.Fix for a crash during an add operation ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160620_2.patch 3. Asyncmeta ignored ors_tlimit if operation timeout was configured in slapd.conf ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160620_3.patch 4. Fixed uninitialized control value during copy of operation, which caused occasional crashes when controls without values are used. ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160620_4.patch 5. Fixed a missing result message if onerr=continue and the last result is an error. ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160620_5.patch 6. Fixed incorrect copy of the entry of an add operation, which resulted in memory leaks. ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160620_6.patch 7.Fixed incorrect copy of Modifications for a modify op, resulting in missing Modifications values ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160620_7.patch 8. Add and modify asyncmeta operations timed-out after a number of operations if the target is unavailable, search operations would occasionally crash under same conditions: ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160620_8.patch

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