openldap-bugs

openldap-bugs@openldap.org

1 participants
21045 discussions

[Issue 10406] New: Write regression since 0.9.19
by openldap-its＠openldap.org 06 Nov '25

06 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10406 Issue ID: 10406 Summary: Write regression since 0.9.19 Product: LMDB Version: 0.9.33 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: ben.alex(a)acegi.com.au Target Milestone: --- I maintain LmdbJava, a Java wrapper for LMDB. We have an extensive benchmark suite covering read, cursor, and write pathways, with isolated testing of LMDB versions from 0.9.17 through 0.9.33. Results: https://lmdb-benchmark.lmdbjava.org/ ============================================== SUMMARY ============================================== Read performance: 0.9.33 consistently outperforms 0.9.17 across all read benchmarks. Write performance: Consistent regression since 0.9.19: ---------------------------------- Tag ms/op vs 0.9.17 ---------------------------------- LMDB_0.9.17 75.790 baseline LMDB_0.9.18 74.909 -1.2% LMDB_0.9.19 81.404 +7.4% LMDB_0.9.20 83.459 +10.1% LMDB_0.9.21 83.237 +9.8% LMDB_0.9.22 83.027 +9.5% LMDB_0.9.23 82.870 +9.3% LMDB_0.9.24 82.952 +9.4% LMDB_0.9.27 82.989 +9.5% LMDB_0.9.28 83.025 +9.5% LMDB_0.9.29 83.063 +9.6% LMDB_0.9.30 83.237 +9.8% LMDB_0.9.31 88.419 +16.7% LMDB_0.9.33 83.304 +9.9% Excluding 0.9.31 as an outlier, write performance degraded by approximately 9% from 0.9.20 and has remained at that level through 0.9.33. ============================================== BENCHMARK DETAILS ============================================== The write benchmark sequentially inserts 1,000,000 entries (100-byte values, 4-byte integer keys) into a database opened with MDB_INTEGERKEY, using a single cursor with MDB_APPEND flag. The benchmark includes 2 warmup iterations and 3 measurement iterations of 120 seconds each. ============================================== ANALYSIS ============================================== Reviewing the commit history, the regressions appear linked to correctness fixes: - 0.9.19: ITS#8406 (xcursor fixup after cursor_del) - 0.9.20: ITS#8557 (cursor_last and C_EOF handling) Both issues added cursor state management overhead in write-heavy code paths. ============================================== REQUEST ============================================== Could you please reproduce this regression using a native C benchmark to confirm it's not JNI-specific? If confirmed, this may be a necessary performance/correctness tradeoff given that most LMDB workloads are read-heavy. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10405] New: freebsd package missing mdb module in openldap server 2.6.10
by openldap-its＠openldap.org 06 Nov '25

06 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10405 Issue ID: 10405 Summary: freebsd package missing mdb module in openldap server 2.6.10 Product: OpenLDAP Version: 2.6.10 Hardware: All OS: FreeBSD Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: enda(a)cronnolly.com Target Milestone: --- When installing openldap server on FreeBSD 14.3, the package: openldap26-server-2.6.10 Open source LDAP server implementation Has the following shared objects in the module folder: ls /usr/local/libexec/openldap/back_*.so /usr/local/libexec/openldap/back_asyncmeta.so /usr/local/libexec/openldap/back_null.so /usr/local/libexec/openldap/back_dnssrv.so /usr/local/libexec/openldap/back_passwd.so /usr/local/libexec/openldap/back_ldap.so /usr/local/libexec/openldap/back_sock.so /usr/local/libexec/openldap/back_meta.so slapd.conf references these modules: # Load dynamic backend modules: modulepath /usr/local/libexec/openldap moduleload back_mdb # moduleload back_ldap but back_mdb is missing from the installed modules. There appears to be no other way to install this module through the package system and the only way to run openldap server 2.6.10 is to build it from ports instead of using the broken package. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9884] New: Document "set" patterns in ACLs
by openldap-its＠openldap.org 06 Nov '25

06 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9884 Issue ID: 9884 Summary: Document "set" patterns in ACLs Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The slapd.access(5) man page has this exceptionally unhelpful line where sets are concerned: "The statement set=<pattern> is undocumented yet." Even if it is an experimental feature, it should still be documented on how it is meant to operate. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9726] New: Admin guide and man pages need better documentation on disabling syslog
by openldap-its＠openldap.org 06 Nov '25

06 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9726 Issue ID: 9726 Summary: Admin guide and man pages need better documentation on disabling syslog Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- 2.6.0 added the new feature allowing using a logfile for all debug/loglevel messages and bypassing syslog entirely. However, there is no documentation on the new settings or examples of how to do this in the admin guide, and the man page sections on the new parameters for the logfile side do not note at when/how they enable bypassing syslog. -- You are receiving this mail because: You are on the CC list for the issue.

1 31

[Issue 10313] New: 3-way multimaster oathHOTPCounter attribute update code missing
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10313 Issue ID: 10313 Summary: 3-way multimaster oathHOTPCounter attribute update code missing Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: agrru01(a)gmail.com Target Milestone: --- I posted on openldap technical mail list and got a response saying I should file a feature request. I am using a 3-way multimaster syncrepl setup with the slapo-otp module. My problem is that when authenticating with a user using HOTP, the attribute oathHOTPCounter only updates the value on the target ldap instance. This means the other two ldap instances do not get the updated HOTP-counter value and therefore will allow authentication using the same HOTP code. Interestingly enough, if I manually edit the oathHOTPCounter value it synchronizes with the other masters. Please see the technical mail list discussion: https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10391] New: Add proper compiler/linker flag for threading support on HP-UX
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10391 Issue ID: 10391 Summary: Add proper compiler/linker flag for threading support on HP-UX Product: OpenLDAP Version: 2.6.10 Hardware: Other OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)innomotics.com Target Milestone: --- Created attachment 1085 --> https://bugs.openldap.org/attachment.cgi?id=1085&action=edit Patch against master If an application uses a thread-enabled library or the application itself is thread enabled it is imperative on HP-UX to use the -mt flag through out build. The compiler will transform into proper -D and -l flags. From the manpage: -mt Sets various -D flags to enable multi-threading. Also sets -lpthread. +Oopenmp automatically implies -mt. For details see HP C/aC++ Online Programmer's Guide. Find a Git-formatted patch attached. Sample output: libtool: link: /opt/aCC/bin/aCC -AC99 +We901 -o ldapsearch ldapsearch.o common.o ldsversion.o -L/opt/ports/lib/hpux32 ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.a -L/opt/ports/lib /var/tmp/ports/work/openldap-threading-hpux/libraries/liblber/.libs/liblber.a ../../libraries/liblber/.libs/liblber.a /opt/ports/lib/hpux32/libsasl2.so -ldl -lssl -lcrypto -mt -Wl,+b -Wl,/opt/ports/lib/hpux32 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 7901] slapschema reports error but returns 0
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=7901 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 7929b3ee by Arvid Requate at 2025-10-22T19:25:34+00:00 ITS#7901 slapschema: preserve errors in -c mode RE26: • 72a16079 by Arvid Requate at 2025-11-04T16:13:34+00:00 ITS#7901 slapschema: preserve errors in -c mode -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10390] New: ldif_parse_line2 calculates an incorrect length of the attribute type
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10390 Issue ID: 10390 Summary: ldif_parse_line2 calculates an incorrect length of the attribute type Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- When parsing a line containing an attribute name and a value, e.g "carLicence : 12344", ldif_parse_line2 calculates the type length incorrectly. It is not clear if this affects any existing code or tools at the moment, but should be fixed. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10388] New: ldif_parse_line2 is not compliant with RFC2849
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10388 Issue ID: 10388 Summary: ldif_parse_line2 is not compliant with RFC2849 Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- RFC2849: Any value that contains characters other than those defined as "SAFE-CHAR", or begins with a character other than those defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded. SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B / %x3D-7F ; any value <= 127 except NUL, LF, CR, ; SPACE, colon (":", ASCII 58 decimal) ; and less-than ("<" , ASCII 60 decimal) However, if the value is not base64 encoded, ldif_parse_line2 (and consequently ldap_parse_ldif_record_x) uses isspace() to just skip any white-space characters at the beginning of at attribute value, icl. tabs. According to the RFC, however, such characters are acceptable. In addition, it does not return an error on LF or CR, just skips them. On the one hand, LDIFs are supposed to be human readable, and fixing this issue may lead to unexpected problems (e.g a stray tab being added to the attribute value). On the other hand, the standard does not exclude %x01-09 and %x0B-0C as valid characters for a non-encoded value. How should we proceed? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10353] New: No TLS connection on Windows because of missing ENOTCONN in socket.h
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10353 Issue ID: 10353 Summary: No TLS connection on Windows because of missing ENOTCONN in socket.h Product: OpenLDAP Version: 2.6.10 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: julien.wadel(a)belledonne-communications.com Target Milestone: --- On Windows, the TLS connection cannot be done and we get the connection error: Can't contact LDAP server. => Connections are done with WSAGetLastError(). After getting WSAEWOULDBLOCK, the connection is not restart because of the state WSAENOTCONN that is not known. OpenLDAP use ENOTCONN that is set to 126 by "ucrt/errno.h" while WSAENOTCONN is 10057L. Adding #define ENOTCONN WSAENOTCONN like for EWOULDBLOCK resolve the issue. Reference commit on external project: https://gitlab.linphone.org/BC/public/external/openldap/-/commit/62fbfb12e8… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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