https://bugs.openldap.org/show_bug.cgi?id=6938
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|VERIFIED |CONFIRMED
Resolution|SUSPENDED |---
--- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
• 90e6bfe0
by Howard Chu at 2025-12-01T16:18:46+00:00
ITS#6938 WIN32: silence warnings for redefined error codes
by Howard Chu at 2025-12-01T16:18:46+00:00
ITS#6938 WIN32 IPv6: fix sockaddr_storage detection
It's defined in winsock2.h. Also remove error for missing INET6_ADDRSTRLEN
define, we already have it in our <ac/socket.h> if it's missing.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9816
Issue ID: 9816
Summary: slapcat cordeumps during mdb subtree dump with -s
Product: OpenLDAP
Version: 2.5.11
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: khoffmann(a)united-internet.de
Target Milestone: ---
Created attachment 887
--> https://bugs.openldap.org/attachment.cgi?id=887&action=edit
gdb backtrace of slapcat run
When trying to use slapcat in combination with -b and -s in order to create a
LDIF backup of a mdb subtree, slapd crashes with a coredump (please see the
attached snippet with gdb output from a reproduced test tree). The problem was
reporducible with different mdb databases / suffixes and only appears with
option -s.
The same dump with -H 'ldap:///ou=users,o=company,c=de??sub?' instead of -s
ou=users,o=company,c=de works perfectly fine, as long as the "attrs part" is
empty in the ldap-uri. Also using slapcat with -b only (for a full database
dump) works fine as well.
I'm aware of the fact that -s option is marked as DEPRECATED - I'm not sure if
you are going to fix this bug or if you rather take the change to remove the
option completely from future major versions.
Please let me also know if it's expected behaviour that the -H option doesn't
work whenever the attribute part isn't empty and if I should contribute to a
documentation update for this edge case.
Best regards,
Kris
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9936
Issue ID: 9936
Summary: slapd attempting free on address which was not
malloced
Product: OpenLDAP
Version: 2.6.3
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: kimjuhi96(a)snu.ac.kr
Target Milestone: ---
I get invalid free running this on the latest openldap from git, built with
CFLAGS="-fsanitize=address" using clang 15.
Seems this is similar to https://bugs.openldap.org/show_bug.cgi?id=9912.
./servers/slapd/slapd -T c -s1 -s1
Stopped reason: SIGABRT
__GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
gdb-peda$ bt
#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff78ca859 in __GI_abort () at abort.c:79
#2 0x00005555556eb04f in __sanitizer::Abort ()
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:143
#3 0x00005555556e8aac in __sanitizer::Die ()
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:58
#4 0x00005555556c5dda in __asan::ScopedInErrorReport::~ScopedInErrorReport
(this=0x7fffffffbe7e, __in_chrg=<optimized out>)
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:192
#5 0x00005555556c72b8 in __asan::ReportFreeNotMalloced (addr=<optimized out>,
free_stack=0x7fffffffca90)
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:199
#6 0x00005555556c02ab in __interceptor_free (ptr=0x7fffffffe359)
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:53
#7 0x0000555555d3efe2 in ber_memfree_x ()
#8 0x0000555555847d33 in ch_free ()
#9 0x0000555555a31178 in slap_tool_init ()
#10 0x0000555555a2e54d in slapcat ()
#11 0x000055555570901f in main ()
#12 0x00007ffff78cc083 in __libc_start_main (main=0x555555706ef0 <main>,
argc=0x5, argv=0x7fffffffdfc8,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffdfb8)
at ../csu/libc-start.c:308
#13 0x000055555561011e in _start ()
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:397
gdb-peda$
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7392
--- Comment #5 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
I'm not so sure this is actually viable, allowing a self<permission> like
what's requested would allow selfwrite with a blanket delete which is contrary
to what our documentation says about selfwrite? Don't know how to square those
two and I think there is a way to write acls that achieve the same intent by
splitting them somewhat?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10362
Issue ID: 10362
Summary: Normalised value confusions in replication
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
A lot of code expects a_nvals state to be consistent across modifies and
multiple instances of the same attribute (with asserts to that effect), but
replication doesn't seem to obey this:
Add this assert into syncrepl_diff_entry()[0] :
assert( ( old->a_nvals == NULL ) == ( new->a_nvals == NULL ) );
if ( old->a_nvals )
assert( ( old->a_nvals == old->a_vals ) == ( new->a_nvals == new->a_vals )
);
You'll see many tests fail this, the first of which is test043.
[0].
https://git.openldap.org/openldap/openldap/-/blob/14d47146b0442df85bd949b21…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10332
Issue ID: 10332
Summary: Add support for SSLKEYLOGFILE environment variable to
export keys for Wireshark decryption
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: michael.osipov(a)siemens.com
Target Milestone: ---
Please add support to do the following:
SSLKEYLOGFILE=keylog.txt ldapsearch -H ldaps://...
Other libraries and tools support it to decrypt the TLS traffic with Wireshark
for analysis purposes.
Curl has a simple, but complete implementation:
https://github.com/curl/curl/blob/e008f71f435a39875d86885a96b2eb8968a60fd4/…
Maybe it can be reused if license allows that?!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10311
Issue ID: 10311
Summary: Work with IETF LDAP working group to update password
hashing mechanism RFC
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: ---
Work with the IETF ldap working group to update the RFC to make the suggested
hashing mechanism be what is currently "best practice" rather than a specific
hashing mechanism.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10100
Issue ID: 10100
Summary: Non-sequential timestamps being logged on Windows
Product: OpenLDAP
Version: 2.6.6
Hardware: x86_64
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: smckinney(a)symas.com
Target Milestone: ---
Presents as a dsync during replication. Consumer will log
```
650af021.2eadd901 0000000000001b40 slap_queue_csn: queueing 0000000002ac1620
20230920131409.992477Z#000000#001#000000
650af021.2eaed239 0000000000001b40 slap_graduate_commit_csn: removing
0000000002ac1620 20230920131409.992477Z#000000#001#000000
650af021.317b2a35 000000000000185c do_syncrep2: rid=102 CSN too old, ignoring
20230920131409.040136Z#000000#001#000000
(uid=slapd-test1-FOO1-6,ou=People,dc=example,dc=com)
```
The entry was not be added.
The provider will log messages using non-sequential timestamps. For example,
when grepping the CSN from above (in provider log):
```
# This:
650af021.3b3060d9 0000000000001ad8 conn=1001 op=1 syncprov_sendresp: to=002,
cookie=rid=102,sid=001,csn=20230920131409.992477Z#000000#001#000000
# and:
650af021.02648749 0000000000001810 slap_get_csn: conn=1003 op=7 generated new
csn=20230920131409.040136Z#000000#001#000000 manage=1
```
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10286
Issue ID: 10286
Summary: ldap_pvt_gettime may result in "not new enough csn"
problems in multi-thread case.
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 971748261(a)qq.com
Target Milestone: ---
Created attachment 1041
--> https://bugs.openldap.org/attachment.cgi?id=1041&action=edit
the log of adding two entry which shows the time sequence.
I used openldap as krb5's database, and openldap was deploymented in
mirrormode.
I tried to add kerberos principals via kadmin.local -q "addprinc -randkey
principal.
slapd log showed that the entry of kadmin/admin was added earlier than the
entry of ossuser. But the csn of kadmin/admin was greater than ossuser.
In this case, when the two entry began to sync to the other slapd server,
ossuser was ignored because of "csn not new enough"
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10277
Issue ID: 10277
Summary: How to deal with desync between cn=config and
back-ldif DNs
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If someone deletes a cn=config entry offline (or through bugs in cn=config,
they exist, will file as I isolate), the X-ORDERED RDNs will not be contiguous.
cn=config papers over this internally at a cost of never being able to modify
the entries affected.
Right now the only remedy is slapcat+slapadd of the whole config DB, is that
the best we can do? When we detect this (doesn't always happen), should we fix
the on-disk copy on startup?
--
You are receiving this mail because:
You are on the CC list for the issue.