- openldap-bugs - openldap.org

[Issue 10241] New: Crash in mdb_page_search_root()
by openldap-its＠openldap.org 22 Jul '24

22 Jul '24

https://bugs.openldap.org/show_bug.cgi?id=10241 Issue ID: 10241 Summary: Crash in mdb_page_search_root() Product: LMDB Version: 0.9.24 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: david.komarek(a)whalebone.io Target Milestone: --- Hello, The LMDB is crashing in mdb_page_search_root() on following instruction `0x7f85221479d2 movzwl 0xa(%rdx),%eax`. This instruction corresponds to following line in source code - https://github.com/LMDB/lmdb/blob/LMDB_0.9.24/libraries/liblmdb/mdb.c#L5485 (while access mp_flags in MDB_page structure) Here is callstack as generated by core dump (without symbols as we're using package from Ubuntu repositories) ``` Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f85221479d2 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 No symbol table info available. #1 0x00007f8522147d15 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 No symbol table info available. #2 0x00007f8522148432 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 No symbol table info available. #3 0x00007f8522148a70 in mdb_get () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 No symbol table info available. ``` Translation ``` #0 mdb_page_search_root() #1 mdb_page_search() #2 mdb_cursor_set() #3 mdb_get() ``` Registers in time of crash: ``` rax 0x2 2 rbx 0x7ffcd8d2a100 140723946168576 rcx 0x3 3 rdx 0x7f825baf7000 140197860700160 rsi 0x1000 4096 rdi 0x7f851c00f4d0 140209677202640 rbp 0x0 0x0 rsp 0x7ffcd8d29e40 0x7ffcd8d29e40 r8 0x7ffcd8d29e50 140723946167888 r9 0x7f851c00f5b8 140209677202872 r10 0x7f851c003090 140209677152400 r11 0x2ce33e6c02ce33e7 3234497591006606311 r12 0x0 0 r13 0x7ffcd8d2a510 140723946169616 r14 0x79 121 r15 0x7f851c003098 140209677152408 rip 0x7f85221479d2 0x7f85221479d2 eflags 0x10246 [ PF ZF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 k0 0x40 64 k1 0xfffff0f0 4294963440 k2 0xff01 65281 k3 0xffffffff 4294967295 k4 0xffffffff 4294967295 k5 0xffffffff 4294967295 k6 0xffffffff 4294967295 k7 0x0 0 ``` Our setup is following: We have single process (running in separate container) which reads and writes to LMDB. It opens environment with following flags MDB_NORDAHEAD|MDB_WRITEMAP|MDB_NOTLS|MDB_NOSYNC. The environment contain several DBs. All DBIs are open with MDB_CREATE flag. Transactions are open without flags. On the other hand we have several processes running in the single container, which are only allowed read (these processes crash). The environment is open with following flags MDB_NORDAHEAD|MDB_WRITEMAP|MDB_NOTLS|MDB_RDONLY. All DBIs are open without flags. Transactions are open with MDB_RDONLY flag. Could you please investigate it? If you will need some other artifacts or comments, please let me know. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10240] New: Information required about the end of support date for OpenLDAP ver 2.6.3
by openldap-its＠openldap.org 16 Jul '24

16 Jul '24

https://bugs.openldap.org/show_bug.cgi?id=10240 Issue ID: 10240 Summary: Information required about the end of support date for OpenLDAP ver 2.6.3 Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: bluesoulprince(a)gmail.com Target Milestone: --- Hi Team, As we have integrated OpenLDAP 2.6.3 version in our application, we would like to know the community support availability end of date for this version, to plan our application maintenance accordingly. Could you please help us with this information. Thanks, Vivek S -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10236] New: fragmentation makes mdb_page_alloc slow
by openldap-its＠openldap.org 16 Jul '24

16 Jul '24

https://bugs.openldap.org/show_bug.cgi?id=10236 Issue ID: 10236 Summary: fragmentation makes mdb_page_alloc slow Product: LMDB Version: 0.9.31 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: aalekseyev(a)janestreet.com Target Milestone: --- Created attachment 1022 --> https://bugs.openldap.org/attachment.cgi?id=1022&action=edit patch is relative to LMDB_0.9.31 It's a known problem that mdb_page_alloc can be slow when the free list is large and fragmented. [1] [2] [3] I'm not sure it's known *how* slow it can be. In our workload we saw a fragmented freelist leading to a pathological O(n^2) behavior. To handle a multi-page allocation we iterate loading chunks of the free list one by one, and at every iteration we do O(n) work to check if the allocation can succeed. Even small-ish allocations (tens of pages) are repeatedly hitting this edge case, with free list growing to ~1000000, and the outer loop taking ~2000 iterations (10^9 worth of work in total, just to allocate a few pages). Even though I'm sure there are ways to avoid hitting this pathological scenario so much (avoid values larger than 4k, or fix whatever causes fragmentation), it seems unacceptable to have a performance cliff this bad. I made a patch to make the allocation take ~O(n*log(n)), by loading and merging multiple chunks at once instead of doing it one-by-one. I'd appreciate it if someone could review the patch (attached), improve it, and/or come up with an alternative fix. The code in `midl.c` is kinda meme-y, including a contribution from GPT-4o, but it performs well enough to speed up our pathological workload by ~20x (which is still ~3x away from the non-fragmented case). Anyway, the main thing that warrants scrutiny is the change in `mdb.c`: I understand very little about lmdb internals and I worry that loading multiple pages at once instead of one-by-one might break something. [1] issue #8664 [2] https://lists.openldap.org/hyperkitty/list/openldap-bugs@openldap.org/threa… [3] 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 10239] New: The slapd domain name is inconsistent, synchronization cannot be modified by the rewrite dn parameter dc.
by openldap-its＠openldap.org 16 Jul '24

16 Jul '24

https://bugs.openldap.org/show_bug.cgi?id=10239 Issue ID: 10239 Summary: The slapd domain name is inconsistent, synchronization cannot be modified by the rewrite dn parameter dc. Product: OpenLDAP Version: 2.4.44 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: 2458943823(a)qq.com Target Milestone: --- /etc/openldap/slapd: syncrepl rid=002 provider=ldap://172.18.1.1 bindmethod=simple binddn="cn=Manager,dc=wsc,dc=ls,dc=com" credentials=lnewnews1tter searchbase="dc=wsc,dc=ls,dc=com" schemachecking=off type=refreshAndPersist retry="60 +" rewrite dn "dc=wsc,dc=ls,dc=com" "dc=wsc,dc=slave1,dc=ls,dc=com" The error is as follows: 66912211 /etc/openldap/slapd.conf: line 281: Error: parse_syncrepl_line: unable to parse "rewrite" . 66912211 failed to add syncinfo slaptest: bad configuration directory! -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10238] New: libldap-2.5-0 kept back from upgrade
by openldap-its＠openldap.org 12 Jul '24

12 Jul '24

https://bugs.openldap.org/show_bug.cgi?id=10238 Issue ID: 10238 Summary: libldap-2.5-0 kept back from upgrade Product: JLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: JLDAP Assignee: bugs(a)openldap.org Reporter: sonny_ward23(a)yahoo.com Target Milestone: --- sonny@sjw-T470p:~$ sudo apt update Ign:1 https://mirrors.ocf.berkeley.edu/linuxmint-packages virginia InRelease Hit:2 https://dl.google.com/linux/chrome/deb stable InRelease Hit:3 https://mirrors.ocf.berkeley.edu/linuxmint-packages virginia Release Hit:4 http://security.ubuntu.com/ubuntu jammy-security InRelease Hit:5 http://mirror.arizona.edu/ubuntu jammy InRelease Hit:6 http://mirror.arizona.edu/ubuntu jammy-updates InRelease Hit:7 http://mirror.arizona.edu/ubuntu jammy-backports InRelease Reading package lists... Done Building dependency tree... Done Reading state information... Done 1 package can be upgraded. Run 'apt list --upgradable' to see it. sonny@sjw-T470p:~$ apt list --upgradable -a Listing... Done libldap-2.5-0/jammy-updates 2.5.18+dfsg-0ubuntu0.22.04.1 amd64 [upgradable from: 2.5.17+dfsg-0ubuntu0.22.04.1] libldap-2.5-0/now 2.5.17+dfsg-0ubuntu0.22.04.1 amd64 [installed,upgradable to: 2.5.18+dfsg-0ubuntu0.22.04.1] libldap-2.5-0/jammy-security 2.5.16+dfsg-0ubuntu0.22.04.2 amd64 libldap-2.5-0/jammy 2.5.11+dfsg-1~exp1ubuntu3 amd64 sonny@sjw-T470p:~$ sudo apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages have been kept back: libldap-2.5-0 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. sonny@sjw-T470p:~$ apt show libldap-2.5-0 -a Package: libldap-2.5-0 Version: 2.5.18+dfsg-0ubuntu0.22.04.1 Priority: optional Section: libs Source: openldap Origin: Ubuntu Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 579 kB Depends: libc6 (>= 2.34), libgnutls30 (>= 3.7.2), libsasl2-2 (>= 2.1.27+dfsg2) Recommends: libldap-common Conflicts: ldap-utils (<= 2.1.23-1) Replaces: libldap-2.3-0, libldap2 Homepage: https://www.openldap.org/ Task: server-minimal, print-server, ubuntu-desktop-minimal, lamp-server, samba-server, ubuntu-desktop, cloud-image, postgresql-server, ubuntu-desktop-raspi, ubuntu-wsl, mail-server, server, ubuntu-server-raspi, kubuntu-desktop, xubuntu-core, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop-core, ubuntustudio-desktop, ubuntukylin-desktop, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop, ubuntu-budgie-desktop-raspi Phased-Update-Percentage: 20 Download-Size: 183 kB APT-Sources: http://mirror.arizona.edu/ubuntu jammy-updates/main amd64 Packages Description: OpenLDAP libraries These are the run-time libraries for the OpenLDAP (Lightweight Directory Access Protocol) servers and clients. Package: libldap-2.5-0 Version: 2.5.17+dfsg-0ubuntu0.22.04.1 Status: install ok installed Priority: optional Section: libs Source: openldap Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Installed-Size: 579 kB Depends: libc6 (>= 2.34), libgnutls30 (>= 3.7.2), libsasl2-2 (>= 2.1.27+dfsg2) Recommends: libldap-common Conflicts: ldap-utils (<= 2.1.23-1) Replaces: libldap-2.3-0, libldap2 Homepage: https://www.openldap.org/ Download-Size: unknown APT-Manual-Installed: yes APT-Sources: /var/lib/dpkg/status Description: OpenLDAP libraries These are the run-time libraries for the OpenLDAP (Lightweight Directory Access Protocol) servers and clients. Package: libldap-2.5-0 Version: 2.5.16+dfsg-0ubuntu0.22.04.2 Priority: optional Section: libs Source: openldap Origin: Ubuntu Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 579 kB Depends: libc6 (>= 2.34), libgnutls30 (>= 3.7.2), libsasl2-2 (>= 2.1.27+dfsg2) Recommends: libldap-common Conflicts: ldap-utils (<= 2.1.23-1) Replaces: libldap-2.3-0, libldap2 Homepage: https://www.openldap.org/ Task: server-minimal, print-server, ubuntu-desktop-minimal, lamp-server, samba-server, ubuntu-desktop, cloud-image, postgresql-server, ubuntu-desktop-raspi, ubuntu-wsl, mail-server, server, ubuntu-server-raspi, kubuntu-desktop, xubuntu-core, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop-core, ubuntustudio-desktop, ubuntukylin-desktop, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop, ubuntu-budgie-desktop-raspi Download-Size: 183 kB APT-Sources: http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages Description: OpenLDAP libraries These are the run-time libraries for the OpenLDAP (Lightweight Directory Access Protocol) servers and clients. Package: libldap-2.5-0 Version: 2.5.11+dfsg-1~exp1ubuntu3 Priority: optional Section: libs Source: openldap Origin: Ubuntu Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 573 kB Depends: libc6 (>= 2.34), libgnutls30 (>= 3.7.2), libsasl2-2 (>= 2.1.27+dfsg2) Recommends: libldap-common Conflicts: ldap-utils (<= 2.1.23-1) Replaces: libldap-2.3-0, libldap2 Homepage: https://www.openldap.org/ Task: server-minimal, print-server, ubuntu-desktop-minimal, lamp-server, samba-server, ubuntu-desktop, cloud-image, postgresql-server, ubuntu-desktop-raspi, ubuntu-wsl, mail-server, server, ubuntu-server-raspi, kubuntu-desktop, xubuntu-core, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop-core, ubuntustudio-desktop, ubuntukylin-desktop, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop, ubuntu-budgie-desktop-raspi Download-Size: 184 kB APT-Sources: http://mirror.arizona.edu/ubuntu jammy/main amd64 Packages Description: OpenLDAP libraries These are the run-time libraries for the OpenLDAP (Lightweight Directory Access Protocol) servers and clients. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10222] New: mdb_dump page has outdated information about user-defined comparison functions
by openldap-its＠openldap.org 28 Jun '24

28 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10222 Issue ID: 10222 Summary: mdb_dump page has outdated information about user-defined comparison functions Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: tools Assignee: bugs(a)openldap.org Reporter: zach.vonler(a)sambanovasystems.com Target Milestone: --- Created attachment 1019 --> https://bugs.openldap.org/attachment.cgi?id=1019&action=edit Patch to mdb_dump man page The `mdb_dump` man page contains an outdated section warning that databases created with user-defined comparison functions cannot be dumped and reloaded without changes to the `mdb_load` program. The `-a` option that was added to the `mdb_load` program in this commit https://github.com/openldap/openldap/commit/7796aaebcd1b937233adab5b1f3d3a1… made it possible to reload such databases, so this patch updates the `mdb_dump` man page to reflect that. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10147] New: Bind dn is getting malformed inside ldap_sasl_bind function
by openldap-its＠openldap.org 25 Jun '24

25 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10147 Issue ID: 10147 Summary: Bind dn is getting malformed inside ldap_sasl_bind function 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: satishkumar1728(a)gmail.com Target Milestone: --- Hi team, We are using open ldap version 2.6 in one of our application processes. We are using ldap_sasl_bind function defined in open ldap api to send bind request to ldap server. We are passing the dn name to the above function and it is parsing the dn name as expected. We have added some print statements inside ldap_sasl_bind function and it is printing the dn string that we passed to the function. Also, ldap_sasl_bind function will accept const char pointer to dn as an argument. So, it cannot modify the dn string inside the function. But somehow the bind dn is getting malformed and we are getting failed bind response from the ldap server (invalid DN). We did some analysis using tcpdump and we found out that the dn string that we passed to the ldap_sasl_bind function and the dn string from the tcpdump are different. We did some code walkthrough of ldap_sasl_bind function and it is observed that it is doing some ber encoding of dn name inside the function. We are suspecting that the encoding is not happening properly. Example dn that we passed to ldap_sasl_bin function: "uid=abc, ou=users, dc=fds, dc=mr" Dn name that was captured in tcpdump at source: "uid=abc, o dc= dc= dc= dc= dc=mr" Is there any specific reason for the bind DN to get malformed like this inside ldap_sasl_bind function. Do you have any observations like this in any scenario. Kindly provide some inputs to resolve this issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10175] New: Secure LDAP is not working on GCC 10.3.0
by openldap-its＠openldap.org 25 Jun '24

25 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10175 Issue ID: 10175 Summary: Secure LDAP is not working on GCC 10.3.0 Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: bluesoulprince(a)gmail.com Target Milestone: --- Hi Team, We have recently migrated our C++ application which is using OpenLDAP 2.6 to GCC version 10.3.0. We are observing difference in LDAP behavior. The non-secure version of LDAP is able to return the result in GCC 10.3.0, however when we switch to secure LDAP, it is not able to return with result. There was no compilation / build issue observed while building our application. Our query is, does secure LDAP from OpenLDAP ver 2.6 have any compatibility issues over GCC 10.3.0? If there are any issues identified over this version, how to resolve those? in which version fixes for them are available? Thanks, Vivek -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[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

[Issue 10182] New: slapo-alias doesn't work with static operational attributes
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10182 Issue ID: 10182 Summary: slapo-alias doesn't work with static operational attributes Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- It only checks in rs->sr_operational_attrs which is for dynamically generated opattrs, and ignores them if they're in the entry itself. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10104] New: Add alias overlay to contrib
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10104 Issue ID: 10104 Summary: Add alias overlay to contrib Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10188] New: autogroup doesn't allow a group to be a member of another group
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10188 Issue ID: 10188 Summary: autogroup doesn't allow a group to be a member of another group Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Try setting up autogroup (autogroup-attrset groupOfURLs memberURL member) and loading the following ldif. You'll notice that neither group is marked as a member: dn: cn=test objectClass: device dn: cn=group,cn=test objectClass: mygroupOfURLs memberURL: ldap:///cn=test??sub?(description=a member) memberURL: ldap:///cn=test??sub?(description=I'm in) description: a member dn: cn=member,cn=test objectClass: device description: I'm in dn: cn=another,cn=test objectClass: mygroupOfURLs memberURL: ldap:///cn=test??sub?(objectclass=groupOfURLs) description: I'm in Just set up mygroupOfURLs with at least a MAY that includes "cn $ description $ member $ memberURL" somehow, e.g. objectClass ( NetscapeLDAPobjectClass:33.1 NAME 'mygroupOfURLs' SUP groupofurls STRUCTURAL MAY member ) -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10172] New: check for writability of directory of logfile during startup
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10172 Issue ID: 10172 Summary: check for writability of directory of logfile during startup Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Even if the logfile itself is writable, if the enclosing directory is not writable then slapd won't be able to perform logfile rotation. Check for this when the logfile is being configured. This will prevent starting up with a bad config, but we still can't do anything about it if the directory's perms are changed while slapd is already running. Logging an error message in that situation would likely fill all disk space with that error message. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10103] New: Contrib OIDs inconsistent
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10103 Issue ID: 10103 Summary: Contrib OIDs inconsistent Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When the latest batch of contrib overlays were added, the OIDs list wasn't updated and OIDs inside the code populated properly. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10197] New: Back-meta and back-asyncmeta add a new target structure and increase the number of targets even if uri parsing fails
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10197 Issue ID: 10197 Summary: Back-meta and back-asyncmeta add a new target structure and increase the number of targets even if uri parsing fails Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- This happens when a new target is added via cn=config. In asyncmeta's case it can lead to too many connection structures allocated, although it seems operational. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10204] New: Slapd crashes when attempting to use DN as constraint attribute
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10204 Issue ID: 10204 Summary: Slapd crashes when attempting to use DN as constraint attribute Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: eresendiz(a)symas.com Target Milestone: --- Created attachment 1016 --> https://bugs.openldap.org/attachment.cgi?id=1016&action=edit Crash output When adding a to the constraint overlay with a constraintattribute that contains a 'dn' filter the slapd process crashes. Please see below for more detail. Very readily produceable with any kind of non-existent attribute specified in the attribute list. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 7400] Memberof and Syncrepl incompatibility
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=7400 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10193] New: Asyncmeta starts more than one timeout loop per database
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10193 Issue ID: 10193 Summary: Asyncmeta starts more than one timeout loop per database Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- By design, there should be always exactly one timeout loop task per database, it is a balance to make sure timeout checks do not throttle traffic processing. For some reason, there seems to be more than one. This is only visible if slapd is started with -dasyncmeta log level. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10207] New: configure: Syntax error: Unterminated quoted string (2.6.8 (RE26))
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10207 Issue ID: 10207 Summary: configure: Syntax error: Unterminated quoted string (2.6.8 (RE26)) Product: OpenLDAP Version: unspecified Hardware: All OS: FreeBSD Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: brett(a)gladserv.com Target Milestone: --- Created attachment 1017 --> https://bugs.openldap.org/attachment.cgi?id=1017&action=edit Patch for configure.ac Testing RE26 (2.6.8) On FreeBSD and NetBSD, configure fails with the following error: checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes ./configure: 13865: Syntax error: Unterminated quoted string Patch for configure.ac attached. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10161] New: Move nested group support to its own overlay
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10161 Issue ID: 10161 Summary: Move nested group support to its own overlay Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Adding the feature to dynlist has made that code overly complex, along with killing performance. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10185] New: autogroup doesn't populate members in newly added dynamic groups
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10185 Issue ID: 10185 Summary: autogroup doesn't populate members in newly added dynamic groups Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- This was broken in 316afb1190c4fa8d96dc56b38b41f4a6ffb163e9 ITS#6970 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10183] New: ldapadd jump option
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10183 Issue ID: 10183 Summary: ldapadd jump option Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Same as the jump option added for slapadd in ITS#4555. Should have been added long ago. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10167] New: slapo-memberof should have a way of reacting to a member entry being added after group referencing it
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10167 Issue ID: 10167 Summary: slapo-memberof should have a way of reacting to a member entry being added after group referencing it Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If a group (with member: values) is added before the member entries exist, the memberof values never get populated. This can happen e.g. during replication. No idea how it meshes with the refint functionality of memberof if it's indeed reconcilable at all. Silly example (Hird's memberof will be empty): ```ldif dn: cn=GNU,ou=Groups,dc=example,dc=com objectClass: groupOfNames member: cn=Hurd,ou=Groups,dc=example,dc=com dn: cn=Hurd,ou=Groups,dc=example,dc=com objectClass: groupOfNames member: cn=Hird,ou=Groups,dc=example,dc=com member: cn=Roger Rabbit,ou=People,dc=example,dc=com dn: cn=Hird,ou=Groups,dc=example,dc=com objectClass: groupOfNames member: cn=Tweety Bird,ou=People,dc=example,dc=com member: cn=Hurd,ou=Groups,dc=example,dc=com ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10186] New: Overlay response callbacks should ignore op->o_abandon
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10186 Issue ID: 10186 Summary: Overlay response callbacks should ignore op->o_abandon Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Overlays that need to perform other DB write operations in their response callbacks usually create a new Operation by copying the existing *op. If the op had its o_abandon flag set, then every op the overlay starts will be immediately abandoned instead of executing. They should zero out the op->o_abandon flag, because the fact that the response callback got invoked means the original operation already completed. If the main op actually observed the abandon request, the response callbacks wouldn't have gotten triggered. This in particular affects the memberof overlay, which must perform other modifications after the main op completes. It also affects the contrib autogroup overlay. It might be relevant for accesslog as well, but I haven't looked at that yet. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10176] New: new atexit() call to atexit(ldap_exit_tls_destroy) in 2.5.17 crashes AIX application
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10176 Issue ID: 10176 Summary: new atexit() call to atexit(ldap_exit_tls_destroy) in 2.5.17 crashes AIX application Product: OpenLDAP Version: 2.5.17 Hardware: Other OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: philip.miloslavsky(a)gmail.com Target Milestone: --- We have a long standing openldap application that's being ported from 2.4.58 to 2.5.17. On ppc AIX (but not on linux for which we also build), when we exit the main application we get a crash in exit() because it is trying to run the atexit which LDAP regsitered, but ldap has already been unloaded and the unloading caused that atexit function pointer to become zero. So I tracked it to this line of code in ldap 2.5.17 that was not there in 2.4.58 libraries/libldap/tls2.c: atexit( ldap_exit_tls_destroy ); If I remove that line of code, my issue goes away. So, now on to dlcose and atexit. So we have a main kernel (irisdb), a C++ library (ldap.so) that we wrote that calls ldap client libraries, and the 2 actual openldap libraries which ldap.so is linked against. During irisdb exit (the h command) irisdb does call dlclose on ldap.so, which as a side effect results in the unloading of the 2 official openldap libraries, but no one calls unatexit() (on the 0x09001000a04947a8 below). After the 3 libraries are unloaded, the atexit registration is still there but its been replaced with zeroes. At what point in this process should we call unatexit or some LDAP function and why does this sequence of events work right on linux but not AIX? [5] stop in ldap_unbind_s (dbx) c [1] stopped in unload_sharedlib at line 7793 in file "/nethome/pmilosla/perforce/projects/OpenLDAP4/kernel/common/src/cdzf.c" ($t1) 7793 if (!libptr) (dbx) where unload_sharedlib(libptr = 0x0000000000000004), line 7793 in "cdzf.c" UnloadZFETable(zfetabdescp = 0x0a00010000032790), line 7346 in "cdzf.c" ResetZFETable(), line 7940 in "cdzf.c" zfrundown(), line 10135 in "cdzf.c" chsub2(), line 3480 in "dmisc2.c" chalt(flag = 1), line 3222 in "dmisc2.c" Chaltcmd(), line 3146 in "dmisc2.c" (dbx) p zfetabdescp->fnameptr "/home/gavlak/gavlakcre7424/bin/ldap.so" (dbx) 0x09001000a04947a8/2x 0x09001000a04947a8: 0900 0000 (dbx) 0x09001000a04947a8/4x 0x09001000a04947a8: 0900 0000 0491 8ec0 (dbx) c [3] stopped in dlclose at 0x90000000029da40 ($t1) 0x90000000029da40 (dlclose) 7c0802a6 mflr r0 (dbx) where dlclose(0x4) at 0x90000000029da40 unload_sharedlib(libptr = 0x0000000000000004), line 7804 in "cdzf.c" UnloadZFETable(zfetabdescp = 0x0a00010000032790), line 7346 in "cdzf.c" ResetZFETable(), line 7940 in "cdzf.c" zfrundown(), line 10135 in "cdzf.c" chsub2(), line 3480 in "dmisc2.c" chalt(flag = 1), line 3222 in "dmisc2.c" Chaltcmd(), line 3146 in "dmisc2.c" (dbx) p zfetabdescp->fnameptr "/home/gavlak/gavlakcre7424/bin/ldap.so" (dbx) c [2] stopped in exit at 0x9000000002524a0 ($t1) 0x9000000002524a0 (exit) 7c0802a6 mflr r0 (dbx) 0x09001000a04947a8/4x 0x09001000a04947a8: 0000 0000 0000 0000 (dbx) c Illegal instruction in . at 0x0 ($t1) 0x0000000000000000 00000000 Invalid opcode. (dbx) where .() at 0x0 exit(??) at 0x900000000252610 syshalt(a = 0), line 6925 in "emisc.c" chalt(flag = 1), line 3227 in "dmisc2.c" Chaltcmd(), line 3146 in "dmisc2.c" -- You are receiving this mail because: You are on the CC list for the issue.

1 17

[Issue 10170] New: accesslog breaks if internal ops done in startup
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10170 Issue ID: 10170 Summary: accesslog breaks if internal ops done in startup Product: OpenLDAP Version: 2.5.17 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- If some other overlay performs some internal operations in its db_open handler, before all DBs and overlays are fully initialized, and accesslog_response is invoked, it may crash if its logDB hasn't been initialized yet. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10044] New: dynlist sometimes crashes when a search operation is abandoned
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10044 Issue ID: 10044 Summary: dynlist sometimes crashes when a search operation is abandoned Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Playing with the DB provided in ITS#10041 on master, interrupting the ldapsearch sometimes leads to a slapd crash. It's not 100% repeatable and the debugger shows dynlist_search2resp touching memory freed by dynlist_search_cleanup already, which doesn't make sense. Might be something else is happening at the same time. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10165] New: back-meta fails to bind to target when proxying an internal operation
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10165 Issue ID: 10165 Summary: back-meta fails to bind to target when proxying an internal operation Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- When the target is configured as follows: idassert-bind bindmethod=sasl saslmech=EXTERNAL authz=proxyauthz flags=override and an overlay issues an internal operation, back-meta attempts to open a new connection to the target, but the bind fails, so the internal operation cannot be executed. The target server returns the following error (as logged by back-meta): <unauthenticated bind (DN with no password) disallowed> Example configuration of the target server: authz-regexp gidNumber=.*\+uidNumber=.*,cn=peercred,cn=external,cn=auth cn=config logfile ./main.log database config database mdb directory ./main rootdn cn=config suffix o=example.com overlay accesslog logdb cn=log logops writes logsuccess true database mdb suffix cn=log directory ./log -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10173] New: Accesslog bootstrap doesn't populate minCSN internally
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10173 Issue ID: 10173 Summary: Accesslog bootstrap doesn't populate minCSN internally Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When a new accesslog DB is being set up from zero but a main DB exists, the correct minCSN is pushed into the auditContainer entry but li_mincsn et al are not set up internally. Fix is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10211] New: uid or gid >= 2^31 can crash slapd when performing peercred auth
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10211 Issue ID: 10211 Summary: uid or gid >= 2^31 can crash slapd when performing peercred auth Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nick(a)portercomputing.co.uk Target Milestone: --- Created attachment 1018 --> https://bugs.openldap.org/attachment.cgi?id=1018&action=edit Patch to resolve issue If a user with uid or gid >= 2^31 performs peercred authentication, slapd can crash due to incorrect formatting of uid and gid when producing the authid string. uid and gid are unsigned int values, but are currently cast to int and printed with %d. This results in values >= 2^31 being printed as negatives, which is wrong, and for some values that will result in a string longer than the space which has been allocated due to the addition of the leading '-'. The issue can be reproduced by attempting a peercred auth from a user with uid and gid 2649996510 - which will currently be printed as -1644970786. Attached is a patch which rectifies this. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10206] New: smbk5pwd.c: implicit declaration of function 'kadm5_s_init_with_password_ctx'
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10206 Issue ID: 10206 Summary: smbk5pwd.c: implicit declaration of function 'kadm5_s_init_with_password_ctx' Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- smbk5pwd.c: In function ‘smbk5pwd_modules_init’: smbk5pwd.c:917:23: warning: implicit declaration of function ‘kadm5_s_init_with_password_ctx’; did you mean ‘kadm5_init_with_password_ctx’? [-Wimplicit-function-declaration] 917 | ret = kadm5_s_init_with_password_ctx( context, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | kadm5_init_with_password_ctx -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10177] New: back-perl build for clang15
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10177 Issue ID: 10177 Summary: back-perl build for clang15 Product: OpenLDAP Version: 2.5.17 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- back-perl cannot be built with clang15 on RHEL9. The following error occurs: ``` libtool: link: clang -shared -fPIC -DPIC .libs/init.o .libs/search.o .libs/close.o .libs/config.o .libs/bind.o .libs/compare.o .libs/modify.o .libs/add.o .libs/modrdn.o .libs/delete.o .libs/version.o -Wl,-rpath -Wl,/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/libldap/.libs -Wl,-rpath -Wl,/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs -Wl,-rpath -Wl,/usr/local/lib -L/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs -L/usr/local/lib -L/usr/lib64/perl5/CORE -lperl -lpthread -lresolv -ldl -lm -lcrypt -lutil ../../../libraries/libldap/.libs/libldap.so /home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs/liblber.so -lsasl2 -lssl -lcrypto ../../../libraries/liblber/.libs/liblber.so -g -O0 -Wl,--enable-new-dtags -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -fstack-protector-strong -Wl,-soname -Wl,back_perl-2.5.so.0 -o .libs/back_perl-2.5.so.0.1.12 .libs/init.o: file not recognized: file format not recognized clang-15: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [Makefile:348: back_perl.la] Error 1 make: Leaving directory '/home/hamano/tmp/openldap-2.5.17/build-clang15/servers/slapd/back-perl' ``` The cause is that the `-flto=auto` flag prevents the generation with ELF format. ``` $ file servers/slapd/back-perl/.libs/init.o servers/slapd/back-perl/.libs/init.o: LLVM IR bitcode ``` I'll open gitlab PR. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10171] New: Incompatible pointer type assignments
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10171 Issue ID: 10171 Summary: Incompatible pointer type assignments Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: sgallagh(a)redhat.com Target Milestone: --- When building with -Werror=incompatible-pointer-types, numerous implicit casts are made from (void**) types. For example: ``` make[3]: Entering directory '/builddir/build/BUILD/openldap-2.6.6/openldap-2.6.6/servers/slapd/back-asyncmeta' /bin/sh ../../../libtool --tag=disable-static --mode=compile gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,--as-needed -DLDAP_CONNECTIONLESS -I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c conn.c libtool: compile: gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,--as-needed -DLDAP_CONNECTIONLESS -I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c conn.c -fPIC -DPIC -o .libs/conn.o make[3]: Leaving directory '/builddir/build/BUILD/openldap-2.6.6/openldap-2.6.6/servers/slapd/back-asyncmeta' make[3]: Entering directory '/builddir/build/BUILD/openldap-2.6.6/openldap-2.6.6/servers/slapd/overlays' /bin/sh ../../../libtool --tag=disable-static --mode=compile gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,--as-needed -DLDAP_CONNECTIONLESS -I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c constraint.c libtool: compile: gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,--as-needed -DLDAP_CONNECTIONLESS -I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c constraint.c -fPIC -DPIC -o .libs/constraint.o make[3]: Leaving directory '/builddir/build/BUILD/openldap-2.6.6/openldap-2.6.6/servers/slapd/overlays' constraint.c:90:38: warning: missing braces around initializer [-Wmissing-braces] 90 | static ConfigTable constraintcfg[] = { | ^ constraint.c:90:38: warning: missing braces around initializer [-Wmissing-braces] constraint.c:90:38: warning: missing braces around initializer [-Wmissing-braces] constraint.c: In function ‘constraint_cf_gen’: constraint.c:327:40: warning: unused variable ‘size’ [-Wunused-variable] 327 | size_t size; | ^~~~ constraint.c:335:40: warning: unused variable ‘count’ [-Wunused-variable] 335 | size_t count; | ^~~~~ constraint.c:560:43: error: assignment to ‘constraint **’ from incompatible pointer type ‘void **’ [-Wincompatible-pointer-types] 560 | for ( app = &on->on_bi.bi_private; *app; app = &(*app)->ap_next ) | ^ constraint.c: In function ‘constraint_check_count_violation’: constraint.c:891:19: warning: unused variable ‘b’ [-Wunused-variable] 891 | BerVarray b = NULL; | ^ constraint.c: In function ‘constraint_update’: constraint.c:1016:26: warning: unused variable ‘ce’ [-Wunused-variable] 1016 | unsigned ce = 0; | ^~ ``` Most of these can be resolved with a simple explicit cast. I have submitted a patch to do so at https://git.openldap.org/openldap/openldap/-/merge_requests/683 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10208] New: build test failure: test076-authid-rewrite (2.6.8 (RE26)
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10208 Issue ID: 10208 Summary: build test failure: test076-authid-rewrite (2.6.8 (RE26) Product: OpenLDAP Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: brett(a)gladserv.com Target Milestone: --- Testing RE26 on Gentoo Linux. Test 076 fails with "generic failure: internal error: failed to init cipher 'rc4'" >>>>> 00:07:19 Starting test076-authid-rewrite for mdb... running defines.sh Starting slapd on TCP/IP port 9011... /home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests Using ldapsearch to check that slapd is running... Checking whether DIGEST-MD5 is supported... Adding schema and database... Using ldapadd to populate the database... Adding olcAuthzRegexp rule for static mapping... Testing ldapwhoami as Manager... ldap_sasl_interactive_bind: Local error (-2) additional info: SASL(-1): generic failure: internal error: failed to init cipher 'rc4' ldapwhoami failed (254)! >>>>> 00:07:20 Failed test076-authid-rewrite for mdb after 1 seconds (exit 254) make[2]: *** [Makefile:320: mdb-yes] Error 254 make[2]: Leaving directory '/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests' make[1]: *** [Makefile:287: test] Error 2 make[1]: Leaving directory '/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests' make: *** [Makefile:298: test] Error 2 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10209] New: OpenBSD Build failure (2.6.8 (RE26)
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10209 Issue ID: 10209 Summary: OpenBSD Build failure (2.6.8 (RE26) Product: OpenLDAP Version: unspecified Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: brett(a)gladserv.com Target Milestone: --- Build failure on OpenBSD 7.2. NB: OpenBSD uses LibreSSL, not OpenSSL, and I have no idea if that's supported, but configure should at least pick that up I think. libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_o.c -fPIC -DPIC -o .libs/tls_o.o tls_o.c:228:19: error: use of undeclared identifier 'OPENSSL_INIT_NO_ATEXIT' OPENSSL_init_ssl(OPENSSL_INIT_NO_ATEXIT, NULL); ^ 1 error generated. *** Error 1 in libraries/libldap (Makefile:432 'tls_o.lo') *** Error 2 in libraries (Makefile:317 'all-common': @for i in liblutil liblber liblunicode libldap librewrite ; do echo " Entering ...) *** Error 2 in /home/bacs/openldap-OPENLDAP_REL_ENG_2_6 (Makefile:325 'all-common': @for i in include libraries clients servers tests doc ; ...) -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10166] New: 2.6.7: not redy for gcc 14.x
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10166 Issue ID: 10166 Summary: 2.6.7: not redy for gcc 14.x Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kloczko.tomasz(a)gmail.com Target Milestone: --- Looks like last version build fails with latest gcc 14.x which is now used in fedora rawhide. cd slapi && make -k all make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/openldap-2.6.7/servers/slapd/slapi' /bin/sh ../../../libtool --mode=compile /usr/bin/gcc -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O2 -g -grecord-gcc-switches -pipe -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdata-sections -ffunction-sections -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -flto=auto -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -Wall -Werror=format-security -DLDAP_CONNECTIONLESS -I../../../include -I.. -I. -I../../../include -I./.. -I. -DSLAPI_LIBRARY -c plugin.c libtool: compile: /usr/bin/gcc -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O2 -g -grecord-gcc-switches -pipe -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdata-sections -ffunction-sections -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -flto=auto -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -Wall -Werror=format-security -DLDAP_CONNECTIONLESS -I../../../include -I.. -I. -I../../../include -I./.. -I. -DSLAPI_LIBRARY -c plugin.c -fPIC -DPIC -o .libs/plugin.o plugin.c: In function 'slapi_int_read_config': plugin.c:697:69: error: passing argument 3 of 'plugin_pblock_new' from incompatible pointer type [-Wincompatible-pointer-types] 697 | pPlugin = plugin_pblock_new( iType, numPluginArgc, c->argv ); | ~^~~~~~ | | | char ** plugin.c:71:21: note: expected 'ConfigArgs *' {aka 'struct config_args_s *'} but argument is of type 'char **' 71 | ConfigArgs *c ) | ~~~~~~~~~~~~^ make[3]: *** [Makefile:387: plugin.lo] Error 1 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10214] New: Reduce library dependencies
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10214 Issue ID: 10214 Summary: Reduce library dependencies Product: OpenLDAP Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- Currently, slapd links libsystemd to notify service state to systemd. However, libsystemd link several unnecessary libraries, which increases security risks. The systemd documentation provides a method to send state notifications to systemd using a simple protocol without the need to link against libsystemd. https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html I propose removing libsystemd and its depended libraries, similar to the approach taken by OpenSSH. Applying this fix reduced the following ten dependencies in the RHEL 8 environment. - libsystemd.so.0 - libblkid.so.1 - libcap.so.2 - libgcc_s.so.1 - libgcrypt.so.20 - libgpg-error.so.0 - liblz4.so.1 - liblzma.so.5 - libmount.so.1 - librt.so.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10179] New: back-asyncmeta(5) man page incorrectly mentions "rewrite"
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10179 Issue ID: 10179 Summary: back-asyncmeta(5) man page incorrectly mentions "rewrite" Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Man page for back-asyncmeta mentions the rewrite options, yet asyncmeta does not support the rewrite engine at the moment. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10164] New: back-meta hangs when used with dynlist overlay
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10164 Issue ID: 10164 Summary: back-meta hangs when used with dynlist overlay Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- When back-meta is configured with the dynlist overlay, on a search request that triggers dynlist, it will hang. This happens because of a bug in back-meta that is only revealed when an overlay issues an internal operation while processing a result or an entry, as dynlist does, as apposed to issuing it when the client op is first received ( on the way "down" to the backend). The issue is reproduced by configuring dynlist over a back-meta database, and sending a subtree search request with the database suffix as dn. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10216] New: Channel binding enforced on AD with AD cert using EDCSA-SHA384 fails
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10216 Issue ID: 10216 Summary: Channel binding enforced on AD with AD cert using EDCSA-SHA384 fails 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: simon.pichugin(a)gmail.com Target Milestone: --- Secure LDAP connections to the target Windows server 2019 DC began failing after the Windows Server DC certificate was updated to an Elliptic Curve Public Key (384 bits) with the sha384ECDSA signature algorithm and sha384 signature hash algorithm specified. The connections were previously successful when the Windows server DC certificate specified an RSA Public Key certificate with signature algorithm sha256RSA and signature hash algorithm sha256 specified. Once the Windows server domain controller certificate is upgraded to the ECC public key, subsequent secure ldap connection attempts fail. If channel binding is turned off on the Windows AD target server, secure ldap connections will succeed using starttls. If Windows server domain controller certificate is upgraded to ECC public key and ldap channel binding is enforced, subsequent secure ldap connection attempts fail with this error message: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090346: LdapErr: DSID-0C09070F, comment: AcceptSecurityContext error, data 80090346, v4563 Expected results: Kerberos SASL should work with STARTTLS even when AD certificate is ECC and SASL_CBINDING is set to "tls-endpoint" Actual results: Kerberos SASL only works with STARTTLS even when AD certificate is RSA and SASL_CBINDING is set to "tls-endpoint"; it fails when AD certificate is ECC Additional information: According to the OpenSSL maintainer, there might be a bug in the OpenLDAP code: it uses EVP_get_digestbynid() to find a digest algorithm based on the signature algorithm, but there might be no such mapping in EC compared to the RSA case. OpenLDAP needs to use OBJ_find_sigid_algs() to find the right algorithm. Possibly, this is the failing code: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… Instead of X509_get_signature_nid() OpenLDAP code probably should call something like OBJ_find_sigid_algs(X509_get_signature_nid(cert), &md_nid, &pk_nid). The former only supports mapping for a few known signature algorithms, but everything did work, most likely due to a fallback to sha256 in case the digest wasn't really found. Judging by https://github.com/openssl/openssl/issues/14278 and https://github.com/openssl/openssl/issues/14467, a better API is coming but not currently available (and as it was in the state for a few years, it probably won't be coming soon) -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10212] New: read-only tools may use wrong meta page
by openldap-its＠openldap.org 14 May '24

14 May '24

https://bugs.openldap.org/show_bug.cgi?id=10212 Issue ID: 10212 Summary: read-only tools may use wrong meta page Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- On a quiescent database that's only used for read-only txns, the txnid won't be initialized so it remains set to zero. Then only meta page zero will get used, even if page one is newer. Thus all information retrieved will be stale by one txn. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9921] New: Tautology in clients/tools/common.c:print_vlv()
by openldap-its＠openldap.org 08 May '24

08 May '24

https://bugs.openldap.org/show_bug.cgi?id=9921 Issue ID: 9921 Summary: Tautology in clients/tools/common.c:print_vlv() Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm… contains: tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE, ldif ? "vlvResult" : "vlvResult", buf, rc ); The second parameter is always vlvResult, irrespective of the value of ldif. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10215] New: [QUESTION] FIPS Validated password hashing
by openldap-its＠openldap.org 07 May '24

07 May '24

https://bugs.openldap.org/show_bug.cgi?id=10215 Issue ID: 10215 Summary: [QUESTION] FIPS Validated password hashing Product: OpenLDAP Version: 2.4.54 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 11tete11(a)gmail.com Target Milestone: --- Hi! we are in process of a certification, and we are using openldap of ubuntu pro fips 20.04, that its the 2.4.54 At some point the auditor ask us, how the passwords are stored into ldap, and we found this: https://github.com/openldap/openldap/tree/master/contrib/slapd-modules/pass… seems that that module do not use a FIPS validated library like "openssl" that comes with ubuntu fips. and make it's own implementation of the sha512. Is there any ldap module that uses the openssl library of the SO that in this case its the openssl 1.1.1f to hash its passwords?, could be this https://github.com/openldap/openldap/tree/master/contrib/slapd-modules/pass… maybe if i'm understanding right? thx! -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10198] New: Crash in mdb_strerr on Windows
by openldap-its＠openldap.org 07 May '24

07 May '24

https://bugs.openldap.org/show_bug.cgi?id=10198 Issue ID: 10198 Summary: Crash in mdb_strerr on Windows Product: LMDB Version: unspecified Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: b.koch(a)beckhoff.com Target Milestone: --- The call to FormatMessageA in mdb_strerr crashes on Windows 10 for error code 112 (disk full). Its "Arguments" parameter is an invalid pointer. The documentation says that the parameter should be ignored because of FORMAT_MESSAGE_IGNORE_INSERTS but my copy of Windows disagrees. Documentation for FormatMessageA: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-form… The error is (with addresses replaced by <...>): Exception thrown at <RtlFormatMessageEx> (ntdll.dll) in ConsoleApplication1.exe: 0xC0000005: Access violation reading location <buf+8*1024>. Trivial fix: Change the last parameter to NULL (in this call: https://github.com/LMDB/lmdb/blob/8645e92b937794c06f0c66dfae64e425a085b6cd/…) Bug 8361 is raising some additional issues in this code and it implies that the va_list is somehow related to the padding hack (but I don't understand how that is, to be honest), so I'm not sure whether the trivial fix would be fine. Here is some code to reproduce the crash outside of liblmdb (tested with Visual Studio 2022, x86 and x64, C++ console project): #include <iostream> #include <windows.h> int main() { std::cout << "Hello World!\n"; char buf[1024]; FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, 112, 0, buf, sizeof(buf), (va_list*)buf + 1024); char* msg = buf; std::cout << msg; } -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10210] New: ldapurl manpage references options that no longer exist
by openldap-its＠openldap.org 30 Apr '24

30 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10210 Issue ID: 10210 Summary: ldapurl manpage references options that no longer exist Product: OpenLDAP Version: 2.6.7 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: --- -h ldaphost Set the host. -p ldapport Set the TCP port. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10195] New: permissive modify control without value
by openldap-its＠openldap.org 30 Apr '24

30 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10195 Issue ID: 10195 Summary: permissive modify control without value Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: lesignor(a)cirad.fr Target Milestone: --- Hello, A windows ldap client (dotnet) format the request with oid permissive modify control like this : 00d0 30 84 00 00 00 1e 04 17 ........0....... 00e0 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 2e 31 1.2.840.113556.1 00f0 2e 34 2e 31 34 31 33 01 01 ff 04 00 .4.1413..... The last 2 bytes 04 00 seems to indicate no value (length of value = 0 ?). With openldap 2.4.x this request was accepted. With openldap 2.5.x or openldap 2.6.x, this request is rejected for invalid protocol with error message : permissiveModify control value not absent With ldapmodify from openldap, the same request is formatted without the last 2 bytes and is accepted. Could it be possible to accept request with control without value formatted with 04 00 to indicate no value ? It will help to migrate from openldap 2.4.x to 2.5.x or 2.6.x Thanks -- You are receiving this mail because: You are on the CC list for the issue.

1 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs