openldap-bugs September 2021

openldap-bugs@openldap.org

1 participants
198 discussions

[Issue 7595] OpenLDAP lacks a ECDHE key generation callback
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=7595 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9687 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7595] OpenLDAP lacks a ECDHE key generation callback
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=7595 --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- (In reply to Howard Chu from comment #1) > Some background info in this thread > http://openssl.6102.n7.nabble.com/Problem-with-cipher-suite-ECDHE-ECDSA- > AES256-SHA384-td42229.html nabble.com seems to have reorganized their domains and the above URL is now broken. The same thread is available at https://www.mail-archive.com/openssl-users@openssl.org/msg69181.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/ -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8341] Matching rules for 'namingContexts'
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8341 --- Comment #9 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Re25: • 2a537ad0 by Ondřej Kuzník at 2021-09-14T16:17:45+00:00 ITS#8341 Allow normalised values for namingContexts in cn=monitor -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8341] Matching rules for 'namingContexts'
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8341 --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: • ea92405a by Ondřej Kuzník at 2021-09-14T16:17:25+00:00 ITS#8341 Allow normalised values for namingContexts in cn=monitor -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8341] Matching rules for 'namingContexts'
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8341 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • bfe3d19e by Ondřej Kuzník at 2021-09-09T10:26:06+01:00 ITS#8341 Allow normalised values for namingContexts in cn=monitor -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9619] New: mdb_env_copy2 with MDB_CP_COMPACT in mdb.master3 produces corrupt mdb file
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9619 Issue ID: 9619 Summary: mdb_env_copy2 with MDB_CP_COMPACT in mdb.master3 produces corrupt mdb file Product: LMDB Version: 0.9.29 Hardware: All OS: Windows Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- When copying an LMDB database with mdb_env_copy2 with the MDB_CP_COMPACT with mdb.master3, the resulting mdb file seems to be corrupt and when using it in LMDB, I get segmentation faults. Copying without the compacting flag seems to work fine. I apologize, I know this is not a very good issue report, as I haven't had a chance to actually narrow this down to a more reproducible/isolated case, or look for how to patch. I thought I would report in case there are any ideas on what could cause this. The segmentation faults always seem to be memory write faults (as opposed to try fault on trying to read). Or perhaps the current backup/copying functionality is eventually going to be replaced by incremental backup/copying anyway (https://twitter.com/hyc_symas/status/1315651814096875520). I'll try to update this if I get a chance to investigate more, but otherwise feel free to ignore/consider low-priority since the work around is easy. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 13 Sep '21

13 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6467 --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE25: commit a00ec090bdcdfdb390ace2238f581ad147e5974f Author: Ondřej Kuzník <ondra(a)mistotebe.net> Date: Tue Jun 1 13:56:58 2021 +0100 ITS#6467 Free uuid list after we're finished -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 13 Sep '21

13 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6467 --- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> --- commit 726a2031334d066a6e463d7b992b6ca7b390e631 Author: Ondřej Kuzník <ondra(a)mistotebe.net> Date: Tue Jun 1 13:56:58 2021 +0100 ITS#6467 Free uuid list after we're finished -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9571] New: Add Behera Draft 8 compatibility flag to ppolicy overlay
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9571 Issue ID: 9571 Summary: Add Behera Draft 8 compatibility flag to ppolicy overlay Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: mhardin(a)symas.com Target Milestone: --- The RFC for Behera Password Policy, Draft, 10 changes modification semantics of certain policy attributes from those that were in effect in Draft 8. To preserve compatibility with applications that depend on the Draft 8 semantics, a compatibility flag needs to be added to the ppolicy configuration that restores the Draft 8 semantics. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9608] New: slapo-syncprov: Replace op on olcSpSessionlog segfault
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9608 Issue ID: 9608 Summary: slapo-syncprov: Replace op on olcSpSessionlog segfault Product: OpenLDAP Version: 2.4.59 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- With the following Syncprov overlay configuration: dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 You can crash slapd with the following modification as the cn=config rootdn: dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config changetype: modify replace: olcSpSessionlog olcSpSessionlog: 10000 GDB backtrace shows: #0 0x00007f7b43f8b954 in sp_cf_gen (c=0x7f7b0761b450) at syncprov.c:3164 on = 0x55d6fb385b90 si = 0x55d6fb35c700 rc = 0 #1 0x000055d6fa4da4ec in config_modify_internal (ca=0x7f7b0761b450, rs=<optimized out>, op=<optimized out>, ce=<optimized out>) at bconfig.c:5773 vals = 0x7f7af8002680 nvals = 0x0 d = <optimized out> e = 0x55d6fb335a38 save_attrs = 0x55d6fb349498 a = 0x55d6fb350180 i = <optimized out> dels = 0x0 rc = <optimized out> oc_at = <optimized out> ct = 0x7f7b441970e0 <spcfg+64> nocs = 3 ptr = <optimized out> s = 0x0 deltail = 0x0 ml = 0x7f7af8102cd0 #2 config_back_modify (op=<optimized out>, rs=<optimized out>) at bconfig.c:5943 cfb = <optimized out> ce = <optimized out> last = 0x55d6fb387f30 ml = <optimized out> ca = {argc = 1, argv = 0x7f7af8103610, argv_size = 513, line = 0x0, tline = 0x0, fname = 0x55d6fa5f5a91 "slapd", lineno = 0, log = "olcSpSessionlog: value #0", '\000' <repeats 4098 times>, reply = {err = 0, msg = "modify/delete: olcSpSessionlog: no such attribute", '\000' <repeats 206 times>}, depth = 0, valx = -1, values = {v_int = 10000, v_uint = 10000, v_long = 10000, v_ulong = 10000, v_ber_t = 10000, v_string = 0x2710 <Address 0x2710 out of bounds>, v_bv = {bv_len = 10000, bv_val = 0x0}, v_dn = {vdn_dn = { bv_len = 10000, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}, v_ad = 0x2710}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 1, type = 2, ca_op = 0x7f7af80028f0, be = 0x55d6fb35c880, bi = 0x55d6fb385b90, ca_entry = 0x55d6fb335a38, ca_private = 0x0, cleanup = 0x0, table = Cft_Overlay} rdn = {bv_len = 10, bv_val = 0x55d6fb385d70 "olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config"} ptr = <optimized out> rad = 0x55d6fb31a570 do_pause = <optimized out> #3 0x000055d6fa508b89 in fe_op_modify (op=0x7f7af80028f0, rs=0x7f7b0761d860) at modify.c:303 update = <optimized out> repl_user = <optimized out> op_be = <optimized out> bd = 0x55d6fa87da80 <slap_frontendDB> textbuf = "\006\000\000\000y\000\000\000\001\000\000\000\300\000\000\000\000\000\000\000\020\001\000\000\000\000\000\000\000\000\000\000P\215.\373\326U\000\000 \307a\a{\177\000\000\006\000\000\000\000\000\000\000u\335P\372\326U\000\000`\330a\a{\177\000\000\344l\207\372\326U\000\000\005\000\000\000\000\000\000\000 \036\000\370z\177\000\000\017\000\000\000\000\000\000\000B[\233G{\177\000\000\064\000\000\000\000\000\000\000\000_Z\004\321WbM\300\307a\a{\177", '\000' <repeats 18 times>, "\320,\020\370z\177\000\000p]5\373\326U", '\000' <repeats 18 times>, "J\227P\372\326U\000\000\200\n\000\370z\177\000\000"... #4 0x000055d6fa50ab7d in do_modify (op=0x7f7af80028f0, rs=0x7f7b0761d860) at modify.c:177 dn = {bv_len = 51, bv_val = 0x7f7af8002867 "olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config"} textbuf = "olcSpSessionlog", '\000' <repeats 240 times> tmp = 0x0 #5 0x000055d6fa4f068c in connection_operation (ctx=ctx@entry=0x7f7b0761dad0, arg_v=arg_v@entry=0x7f7af80028f0) at connection.c:1182 rc = 80 cancel = <optimized out> op = 0x7f7af80028f0 rs = {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} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x55d6fb522120 memctx = 0x7f7af8000a80 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #6 0x000055d6fa4f09fb in connection_read_thread (ctx=0x7f7b0761dad0, argv=0xb) at connection.c:1318 rc = <optimized out> cri = {op = 0x7f7af80028f0, func = 0x0, arg = 0x0, ctx = <optimized out>, nullop = <optimized out>} s = <optimized out> #7 0x00007f7b4937527a in ldap_int_thread_pool_wrapper (xpool=0x55d6fb3101d0) at tpool.c:696 pool = 0x55d6fb3101d0 task = 0x7f7b00000b40 work_list = <optimized out> ctx = {ltu_id = 140166381561600, ltu_key = {{ltk_key = 0x55d6fa4ee6a0 <conn_counter_init>, ltk_data = 0x7f7af8002710, ltk_free = 0x55d6fa4ee780 <conn_counter_destroy>}, {ltk_key = 0x55d6fa549200 <slap_sl_mem_init>, ltk_data = 0x7f7af8000a80, ltk_free = 0x55d6fa5490c0 <slap_sl_mem_destroy>}, {ltk_key = 0x55d6fa504fd0 <slap_op_free>, ltk_data = 0x0, ltk_free = 0x55d6fa504f30 <slap_op_q_destroy>}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 26 times>, {ltk_key = 0x0, ltk_data = 0x7f7b484ffd61 <_L_unlock_3056+19>, ltk_free = 0x0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #8 0x00007f7b484feea5 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #9 0x00007f7b479bb9fd in clone () from /lib64/libc.so.6 No symbol table info available. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

← Newer
1
...
13
14
15
16
17
18
19
20
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2021