openldap-bugs June 2024

openldap-bugs@openldap.org

2 participants
66 discussions

[Issue 10140] New: Add microsecond timestamp format for local file logging
by openldap-its＠openldap.org 20 Jun '24

20 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10140 Issue ID: 10140 Summary: Add microsecond timestamp format for local file logging Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gnoe(a)symas.com Target Milestone: --- Add microsecond-level timestamps to local file logging. Format is: "YYYY-mm-ddTHH:MM:SS.ffffffZ" 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 Gregory Noe gnoe(a)symas.com. I have not assigned rights and/or interest in this work to any party. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2023 Gregory Noe Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10228] New: config LDAP_BACK_CONN_PRIV_MAX to higher value
by openldap-its＠openldap.org 18 Jun '24

18 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10228 Issue ID: 10228 Summary: config LDAP_BACK_CONN_PRIV_MAX to higher value Product: OpenLDAP Version: 2.5.16 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: shaosong.li(a)salesforce.com Target Milestone: --- Hi, LDAP_BACK_CONN_PRIV_MAX parameter is set to 256 by below config, https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/serv… Can we set this value to a higher value, such as 7k/10k, which is commonly used in PingDirectory. Any reason that we set this value to a low value like 256, thanks. -- You are receiving this mail because: You are on the CC list for the issue.

2 8

[Issue 10060] New: libldap: ldap_result return value differs depending on if a search response is already in the response list or not
by openldap-its＠openldap.org 18 Jun '24

18 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10060 Issue ID: 10060 Summary: libldap: ldap_result return value differs depending on if a search response is already in the response list or not Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: david(a)hardeman.nu Target Milestone: --- ldap_result(3) is defined here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… On this line, ldap_result will call wait4msg: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… wait4msg is defined here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… If a response for a given msgid is already stored in the response list, and all=1, the whole message chain will be returned by the call from wait4msg to chkResponseList here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… And rc will be set on the next line to the head of the message chain. If a response for a given msgid is *not* already stored in the response list, wait4msg will eventually call try_read1msg here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… If try_read1msg manages to receive the final search result message for a given msgid, it will be noted here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… The whole chain will be returned here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… And the return code will be the tag of the *last* message in the chain, as opposed to the *first* message in the chain: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… Which will result in different return codes for chains of multiple messages (i.e. search results with all=1). -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 10138] New: Allow generating multiple nested read transactions from a write transaction
by openldap-its＠openldap.org 18 Jun '24

18 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10138 Issue ID: 10138 Summary: Allow generating multiple nested read transactions from a write transaction Product: LMDB Version: 0.9.30 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Hello, I have a feature request. Would it be possible to read a database from the point of view of a non-yet-committed write transaction? What I want to do is to write a lot of entries into a database, use a couple of threads to read those entries (using MDB_NOTLS) to generate a lot of new entries (that will be written to disk and then once the generation is done, drop the read-transaction handles and write (with MDB_APPEND) those new entries from disk into LMDB. This would have been possible if I had committed the first entries, but unfortunately, it is impossible. I need to do this in the same transaction. Have a great day, kero -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10225] New: tlso_session_pinning: will crash if digest/keyhash.bv_val is not properly initialized over the lifetime of the function
by openldap-its＠openldap.org 07 Jun '24

07 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10225 Issue ID: 10225 Summary: tlso_session_pinning: will crash if digest/keyhash.bv_val is not properly initialized over the lifetime of the function Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: yaneurabeya(a)gmail.com Target Milestone: --- tlso_session_pinning(..) does not initialize the `digest` stack memory before referring to it later on in the function. This can result in a library crash if (for whatever reason) keyhash.bv_val fails to initialize properly on line 1191 [1]. This issue kind of goes hand in hand with bug 10224. 1. https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10220] New: Feature Request: new option for append-only write transaction
by openldap-its＠openldap.org 31 May '24

31 May '24

https://bugs.openldap.org/show_bug.cgi?id=10220 Issue ID: 10220 Summary: Feature Request: new option for append-only write transaction Product: LMDB Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: xhtang518(a)gmail.com Target Milestone: --- My project uses LMDB to store values larger than 100KB, and rarely delete values. So I can afford wasting some space on free pages, then LMDB can reduce 4KB-write operations and improve write performance when committing write transactions. I suppose this feature is not hard to implement: just pretend the free-list is empty in this transaction if the new option is present. Is this feature reasonable? -- You are receiving this mail because: You are on the CC list for the issue.

1 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2024