- openldap-bugs - openldap.org

[Issue 9045] Crashes in cn=config (test050)
by openldap-its＠openldap.org 01 Nov '22

01 Nov '22

https://bugs.openldap.org/show_bug.cgi?id=9045 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|CONFIRMED |RESOLVED --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • a6f3106a by Ondřej Kuzník at 2022-10-31T18:16:42+00:00 ITS#9045 Do not share cn=config entries with outside code RE26: • 99a7c141 by Ondřej Kuzník at 2022-11-01T17:05:36+00:00 ITS#9045 Do not share cn=config entries with outside code RE25: • ce7a7997 by Ondřej Kuzník at 2022-11-01T17:07:15+00:00 ITS#9045 Do not share cn=config entries with outside code -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9045] Crashes in cn=config (test050)
by openldap-its＠openldap.org 31 Oct '22

31 Oct '22

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

1 0

[Issue 9938] New: Deprecate STARTTLS, recommend LDAPS
by openldap-its＠openldap.org 31 Oct '22

31 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9938 Issue ID: 9938 Summary: Deprecate STARTTLS, recommend LDAPS Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: martin.von.wittich(a)iserv.eu Target Milestone: --- This has been discussed on the mailing list before, but unfortunately it seems to have gotten lost in the shuffle: https://www.openldap.org/lists/openldap-technical/201802/msg00004.html > To me this rationale for SMTP submission with implicit TLS seems also > applicable to LDAPS vs. StartTLS: > > https://tools.ietf.org/html/rfc8314#appendix-A > > So LDAPS should not be considered deprecated. Rather it should be > recommended and the _optional_ use of StartTLS should be strongly > discouraged. Currently, https://www.openldap.org/faq/data/cache/605.html (Start TLS v. ldaps://) still recommends STARTTLS over LDAPS. This unfortunately leads LDAP client implementers to create clients that only support STARTTLS, e.g. here: https://github.com/odoo/odoo/issues/9772#issuecomment-159943316 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9943] New: pw-radius
by openldap-its＠openldap.org 28 Oct '22

28 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9943 Issue ID: 9943 Summary: pw-radius Product: OpenLDAP Version: 2.4.57 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: earyutin(a)gmail.com Target Milestone: --- Good evening, dear developers! I'm using Debian 11 Faced with the problem of compiling the module for authorization through FreeRadius, users connecting to OpenLDAP. There is little information on the net, but I managed to find the following: https://github.com/openldap/openldap/blob/master/contrib/slapd-modules/pass… moduleload pw-radius.so gcc -shared -I../../../include -Wall -g -o pw-radius.so radius.c -lradius Installed: apt install slapd ldap-utils Version: slapd -V @(#) $OpenLDAP: slapd 2.4.57+dfsg-3+deb11u1 gcc -shared -I /usr/lib/ldap/ -Wall -g -o pw-radius.so radius.c -lradius gcc: error: radius.c: No such file or directory 1. Download "openldap-2.5.13.tgz" 2. tar -zxvf openldap-2.5.13.tgz 3. find /root/openldap-2.5.13/ -name "radius.c" /root/openldap-2.5.13/contrib/slapd-modules/passwd/radius.c 4. cd /root/openldap-2.5.13/contrib/slapd-modules/passwd/ 5. gcc -shared -I ../../../include -Wall -g -o pw-radius.so radius.c -lradius" Errors appear 5.1. radius.c:16:10: fatal error: portable.h: No such file or directory 16 | #include "portable.h" 5.2. find /root/openldap-2.5.13/ -name "portable.*" /root/openldap-2.5.13/include/portable.hin 5.3. cp /root/openldap-2.5.13/include/portable.hin /root/openldap-2.5.13/include/portable.h 5.4. gcc -shared -I ../../../include -Wall -g -o pw-radius.so radius.c -lradius" 5.5. In file included from radius.c:16: ../../../include/portable.h:1188:10: fatal error: ldap_features.h: No such file or directory 1188 | #include "ldap_features.h" 5.6. find /root/openldap-2.5.13/ -name "ldap_features.*" /root/openldap-2.5.13/include/ldap_features.hin cp /root/openldap-2.5.13/include/ldap_features.hin /root/openldap-2.5.13/include/ldap_features.h ... After changing the names of all bad files, a bunch of errors come out: gcc -shared -I ../../../include -Wall -g -o pw-radius.so radius.c -lradius In file included from ../../../include/lber.h:29, from radius.c:20: ../../../include/lber_types.h:42:9: error: unknown type name ‘LBER_INT_T’ 42 | typedef LBER_INT_T ber_int_t; | ^~~~~~~~~~ ../../../include/lber_types.h:45:27: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ber_sint_t’ 45 | typedef signed LBER_INT_T ber_sint_t; | ^~~~~~~~~~ ../../../include/lber_types.h:46:29: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ber_uint_t’ 46 | typedef unsigned LBER_INT_T ber_uint_t; | ^~~~~~~~~~ ../../../include/lber_types.h:49:29: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ber_tag_t’ 49 | typedef unsigned LBER_TAG_T ber_tag_t; | ^~~~~~~~~ ../../../include/lber_types.h:52:9: error: unknown type name ‘LBER_SOCKET_T’ 52 | typedef LBER_SOCKET_T ber_socket_t; | ^~~~~~~~~~~~~ ../../../include/lber_types.h:55:29: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ber_len_t’ 55 | typedef unsigned LBER_LEN_T ber_len_t; | ^~~~~~~~~ ../../../include/lber_types.h:58:27: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ber_slen_t’ 58 | typedef signed LBER_LEN_T ber_slen_t; | ^~~~~~~~~~ In file included from ../../../include/portable.hin:1187, from radius.c:16: ../../../include/lber.h:121:42: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 121 | typedef void* (BER_MEMALLOC_FN) LDAP_P(( ber_len_t size, void *ctx )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:122:43: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 122 | typedef void* (BER_MEMCALLOC_FN) LDAP_P(( ber_len_t n, ber_len_t size, void *ctx )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:122:56: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 122 | typedef void* (BER_MEMCALLOC_FN) LDAP_P(( ber_len_t n, ber_len_t size, void *ctx )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:123:53: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 123 | typedef void* (BER_MEMREALLOC_FN) LDAP_P(( void *p, ber_len_t size, void *ctx )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ In file included from radius.c:20: ../../../include/lber.h:127:2: error: unknown type name ‘BER_MEMALLOC_FN’ 127 | BER_MEMALLOC_FN *bmf_malloc; | ^~~~~~~~~~~~~~~ ../../../include/lber.h:128:2: error: unknown type name ‘BER_MEMCALLOC_FN’ 128 | BER_MEMCALLOC_FN *bmf_calloc; | ^~~~~~~~~~~~~~~~ ../../../include/lber.h:129:2: error: unknown type name ‘BER_MEMREALLOC_FN’ 129 | BER_MEMREALLOC_FN *bmf_realloc; | ^~~~~~~~~~~~~~~~~ ../../../include/lber.h:191:2: error: expected specifier-qualifier-list before ‘ber_slen_t’ 191 | ber_slen_t (*sbi_read)( Sockbuf_IO_Desc *sbiod, void *buf, | ^~~~~~~~~~ ../../../include/lber.h:213:2: error: unknown type name ‘ber_len_t’ 213 | ber_len_t bv_len; | ^~~~~~~~~ In file included from ../../../include/portable.hin:1187, from radius.c:16: ../../../include/lber.h:230:25: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 230 | LDAP_CONST char *data, ber_len_t len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:244:9: error: unknown type name ‘ber_tag_t’ 244 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:248:9: error: unknown type name ‘ber_tag_t’ 248 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:251:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 251 | ber_len_t *len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:253:9: error: unknown type name ‘ber_tag_t’ 253 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:256:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 256 | ber_len_t *len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:258:9: error: unknown type name ‘ber_tag_t’ 258 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:263:9: error: unknown type name ‘ber_tag_t’ 263 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:268:9: error: unknown type name ‘ber_tag_t’ 268 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:273:9: error: unknown type name ‘ber_tag_t’ 273 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:278:9: error: unknown type name ‘ber_tag_t’ 278 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:288:9: error: unknown type name ‘ber_tag_t’ 288 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:292:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 292 | ber_len_t *len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:301:9: error: unknown type name ‘ber_tag_t’ 301 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:307:9: error: unknown type name ‘ber_tag_t’ 307 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:312:9: error: unknown type name ‘ber_tag_t’ 312 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:317:9: error: unknown type name ‘ber_tag_t’ 317 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:321:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 321 | ber_len_t *len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:323:9: error: unknown type name ‘ber_tag_t’ 323 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:327:9: error: unknown type name ‘ber_tag_t’ 327 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:332:9: error: unknown type name ‘ber_tag_t’ 332 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:335:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 335 | ber_len_t *len, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:338:9: error: unknown type name ‘ber_tag_t’ 338 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:341:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 341 | ber_len_t *len, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:344:9: error: unknown type name ‘ber_tag_t’ 344 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:371:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 371 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:377:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 377 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:383:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 383 | ber_len_t len, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:384:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 384 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:390:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 390 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:396:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 396 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:402:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 402 | ber_len_t bitlen, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:403:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 403 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:408:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 408 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:414:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 414 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:419:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 419 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:424:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 424 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:445:9: error: unknown type name ‘ber_slen_t’ 445 | LBER_F( ber_slen_t ) | ^~~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:448:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 448 | ber_len_t len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:450:9: error: unknown type name ‘ber_slen_t’ 450 | LBER_F( ber_slen_t ) | ^~~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:454:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 454 | ber_len_t len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:456:9: error: unknown type name ‘ber_slen_t’ 456 | LBER_F( ber_slen_t ) | ^~~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:460:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 460 | ber_len_t len, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:501:9: error: unknown type name ‘ber_tag_t’ 501 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:504:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 504 | ber_len_t *len, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:600:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 600 | ber_len_t s )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:605:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 605 | ber_len_t s )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:609:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 609 | ber_len_t n, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:610:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 610 | ber_len_t s )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:643:21: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 643 | LDAP_CONST char *, ber_len_t len, int duplicate, struct berval *bv)); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:647:21: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 647 | LDAP_CONST char *, ber_len_t len, int duplicate, struct berval *bv)); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:656:9: error: unknown type name ‘ber_len_t’ 656 | LBER_F( ber_len_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:658:22: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 658 | LDAP_CONST char *s, ber_len_t len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:662:22: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 662 | LDAP_CONST char *s, ber_len_t l )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ In file included from radius.c:21: ../../../include/lber_pvt.h:45:2: error: unknown type name ‘ber_len_t’ 45 | ber_len_t buf_size; | ^~~~~~~~~ ../../../include/lber_pvt.h:46:2: error: unknown type name ‘ber_len_t’ 46 | ber_len_t buf_ptr; | ^~~~~~~~~ ../../../include/lber_pvt.h:47:2: error: unknown type name ‘ber_len_t’ 47 | ber_len_t buf_end; | ^~~~~~~~~ In file included from ../../../include/portable.hin:1187, from radius.c:16: ../../../include/lber_pvt.h:66:9: error: unknown type name ‘ber_slen_t’ 66 | LBER_F( ber_slen_t ) | ^~~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber_pvt.h:76:51: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 76 | ber_pvt_sb_grow_buffer LDAP_P(( Sockbuf_Buf *buf, ber_len_t minsize )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber_pvt.h:78:9: error: unknown type name ‘ber_len_t’ 78 | LBER_F( ber_len_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber_pvt.h:79:59: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 79 | ber_pvt_sb_copy_out LDAP_P(( Sockbuf_Buf *sbb, char *buf, ber_len_t len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber_pvt.h:89:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 89 | ber_len_t s, void *ctx)); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber_pvt.h:94:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 94 | ber_len_t s, void *ctx )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber_pvt.h:98:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 98 | ber_len_t n, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber_pvt.h:99:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 99 | ber_len_t s, void *ctx )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber_pvt.h:128:21: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 128 | LDAP_CONST char *, ber_len_t len, int dup, struct berval *bv, void *ctx)); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber_pvt.h:132:21: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 132 | LDAP_CONST char *, ber_len_t len, int dup, struct berval *bv, void *ctx)); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ In file included from ../../../include/lutil.h:21, from radius.c:22: ../../../include/ac/socket.h:233:46: error: unknown type name ‘uid_t’ 233 | LDAP_LUTIL_F( int ) lutil_getpeereid( int s, uid_t *, gid_t * ); | ^~~~~ ../../../include/ac/socket.h:233:55: error: unknown type name ‘gid_t’ 233 | LDAP_LUTIL_F( int ) lutil_getpeereid( int s, uid_t *, gid_t * ); | ^~~~~ ../../../include/ac/socket.h:238:18: error: field ‘sa_addr’ has incomplete type 238 | struct sockaddr sa_addr; | ^~~~~~~ ../../../include/ac/socket.h:239:21: error: field ‘sa_in_addr’ has incomplete type 239 | struct sockaddr_in sa_in_addr; | ^~~~~~~~~~ In file included from ../../../include/portable.hin:1187, from radius.c:16: ../../../include/lutil.h:68:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 68 | ber_len_t nbytes )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lutil.h:137:51: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 137 | lutil_passwd_generate LDAP_P(( struct berval *pw, ber_len_t )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ radius.c:27:10: fatal error: radlib.h: No such file or directory 27 | #include <radlib.h> Help me please. Thank you ! -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 5693] [enhancement] extension of slapo-translucent filtering approach
by openldap-its＠openldap.org 25 Oct '22

25 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=5693 --- Comment #5 from salleman(a)math.u-bordeaux.fr --- Hi, I have a similar issue with search on translucent overlay : I override ObjectClass with posixAccount. I set translucent with : olcTranslucentLocal: uidNumber olcTranslucentLocal: gidNumber olcTranslucentLocal: homeDirectory olcTranslucentLocal: loginShell olcTranslucentLocal: mailAlternateAddress olcTranslucentLocal: memberUid olcTranslucentLocal: objectClass It works except when I search with filter like this : "(&(loginShell=/bin/bash)(sn=Smith))". On the remote backend, the search is : SRCH base="uid=dupont,ou=people,dc=u-bordeaux,dc=fr" scope=0 deref=0 filter="(objectClass=*) SEARCH RESULT tag=101 err=0 qtime=0.000013 etime=0.000146 nentries=1 text=" which is a entry contains loginShell=/bin/bash. It seems that when a composed filter with local and remote attributes returns many results from local (loginShell), the search on remote would apply for each dn founds but translucent fails on the first (because second part of filter is not verified (sn=Smith)). -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9045] Crashes in cn=config (test050)
by openldap-its＠openldap.org 24 Oct '22

24 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9045 --- Comment #4 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Created attachment 926 --> https://bugs.openldap.org/attachment.cgi?id=926&action=edit A more recent crash -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9045] Crashes in cn=config (test050)
by openldap-its＠openldap.org 24 Oct '22

24 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9045 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CONFIRMED Ever confirmed|0 |1 Resolution|WORKSFORME |--- --- Comment #3 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Got another one, in do_syncrep1, attached. I gather it's because syncrepl got it through entry_get() while there is a modify request on cn=config that freed it in the meantime. Sounds like ldap_pvt_thread_rdwr_rlock( &cfb->cb_rwlock ) in config_back_entry_get (and the reverse in config_entry_release()) might do the trick, except that anyone getting that entry needs to release it before they yield processing - as bconfig might decide it wants to pause and wlock. Or we just entry_dup it unconditionally which means we never interfere with anyone else. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9939] New: datamorph test fails
by openldap-its＠openldap.org 24 Oct '22

24 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9939 Issue ID: 9939 Summary: datamorph test fails Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: patrick+openldap.org(a)laimbock.com Target Milestone: --- [snip] + for MOD in datamorph ppm variant + pushd contrib/slapd-modules/datamorph ~/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph ~/build/BUILD/openldap-2.6.3 + /usr/bin/make -O -j1 V=1 VERBOSE=1 test ln -s /builddir/build/BUILD/openldap-2.6.3/clients clients ln -s /builddir/build/BUILD/openldap-2.6.3/servers servers ln -s /builddir/build/BUILD/openldap-2.6.3/tests/progs tests/progs cd tests; \ SRCDIR=/builddir/build/BUILD/openldap-2.6.3 \ LDAP_BUILD=/builddir/build/BUILD/openldap-2.6.3 \ TOPDIR=/builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph \ LIBTOOL=/builddir/build/BUILD/openldap-2.6.3/libtool \ /builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/run all Running /builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/scripts/all for mdb... >>>>> Executing all LDAP tests for mdb >>>>> Starting test001-config for mdb... running defines.sh /builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/scripts/common.sh: line 26: /servers/slapd/slapd: No such file or directory /builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/scripts/common.sh: line 28: /servers/slapd/slapd: No such file or directory Starting slapd on TCP/IP port 9011 for configuration... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Failed testing for module load entry >>>>> test001-config failed for mdb (exit 127) make: *** [tests/Rules.mk:12: test] Error 127 This test also fails on the latest 2.6 branch. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8610] ldaps not usable with DNS SRV
by openldap-its＠openldap.org 21 Oct '22

21 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=8610 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- The FAQ is historic, 99% of what's in it is incorrect. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9933] New: pamcompany
by openldap-its＠openldap.org 18 Oct '22

18 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9933 Issue ID: 9933 Summary: pamcompany Product: JLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: JDBC Assignee: bugs(a)openldap.org Reporter: packersnmoversservices(a)gmail.com Target Milestone: --- A trustworthy and expert moving business in Bangalore's Hebbal is PAM Bangalore. This business is regarded as one of the top packers and movers hebbal service providers because of its reputation for offering high-quality moving and shifting services at reasonable pricing. Relocators who require storage or house transferring services in Bangalore seek them. A firm with a team of professional packers and movers offers a hassle-free, damage-free, and stress-free move at a reasonable cost. https://www.packersmoversinbangalore.co.in/packers-and-movers-in-hebbal/ -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9927] New: mdb/0.9 update makes strange problems
by openldap-its＠openldap.org 13 Oct '22

13 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9927 Issue ID: 9927 Summary: mdb/0.9 update makes strange problems Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Created attachment 919 --> https://bugs.openldap.org/attachment.cgi?id=919&action=edit strace outfput of failed start I changed on the 2.6 branch at this commit 18f6cc1609fe80ae30702f68875a6fc793e29ffd (origin/OPENLDAP_REL_ENG_2_6, OPENLDAP_REL_ENG_2_6) Merge: 8b4c915a6 d87d682b6 Author: Quanah Gibson-Mount <quanah(a)openldap.org> Date: Tue Oct 4 14:29:39 2022 +0000 Merge remote-tracking branch 'origin/mdb.RE/0.9' into OPENLDAP_REL_ENG_2_6 and things stopped working: after several times restarting slapd refused to start. Then I went back to commit: commit 8b4c915a655373973a834719f942bcdc09a7b516 (HEAD) Author: Quanah Gibson-Mount <quanah(a)openldap.org> Date: Mon Oct 3 20:26:19 2022 +0000 ITS#9915 and things worked again. I changed back to commit 18f6cc1609fe8, and slapd does run properly. Of course, I assume the LMDB database format has not changed and I have not done export to LDIF and then import from LDIF to LMDB. I have disabled syslog and debugging: $ ./configure --disable-ipv6 --enable-spasswd --disable-static --disable-syslog --disable-debug --enable-sssvlv --disable-relay The file FAILED.txt, produced on dysfunctional slapd by executing # strace /usr/local/libexec/slapd -d0 -u openldap -r /home/openldap -F /etc/openldap/ -h'ldap://ldap.aegee.org/ ldaps://ldap.aegee.org ldapi://%%2Fvar%%2Frun%%2Fldapi' > FAILED.txt is attached. This is very similar to https://bugs.openldap.org/show_bug.cgi?id=9879 : upgrading to the newest version fails. Using a slightly older version than the tip of the tree does not fail any more. Then upgrading to the newest version does work. Note that yesterday, or two-three days ago I also upgraded to the newest tip of git and things worked, but I cannot say which commit was this. # journalctl --unit openldap Oct 04 08:04:31 mail systemd[1]: Stopping OpenLDAP... Oct 04 08:04:33 mail systemd[1]: openldap.service: Deactivated successfully. Oct 04 08:04:33 mail systemd[1]: Stopped OpenLDAP. Oct 04 08:04:33 mail systemd[1]: openldap.service: Consumed 50.080s CPU time. Oct 04 08:04:33 mail systemd[1]: Starting OpenLDAP... Oct 04 08:04:36 mail systemd[1]: Started OpenLDAP. Oct 04 08:10:33 mail systemd[1]: Stopping OpenLDAP... Oct 04 08:10:34 mail systemd[1]: openldap.service: Deactivated successfully. Oct 04 08:10:34 mail systemd[1]: Stopped OpenLDAP. Oct 04 08:10:37 mail systemd[1]: Starting OpenLDAP... Oct 04 08:10:37 mail systemd[1]: Started OpenLDAP. Oct 05 07:33:36 mail systemd[1]: Stopping OpenLDAP... Oct 05 07:33:37 mail systemd[1]: openldap.service: Failed with result 'resources'. Oct 05 07:33:37 mail systemd[1]: Stopped OpenLDAP. Oct 05 07:33:37 mail systemd[1]: openldap.service: Consumed 7.453s CPU time. Oct 05 07:33:37 mail systemd[1]: Starting OpenLDAP... Oct 05 07:33:38 mail systemd[1]: openldap.service: Main process exited, code=exited, status=255/EXCEPTION Oct 05 07:33:38 mail systemd[1]: openldap.service: Failed with result 'exit-code'. Oct 05 07:33:38 mail systemd[1]: Failed to start OpenLDAP. Oct 05 07:33:43 mail systemd[1]: Starting OpenLDAP... Oct 05 07:33:43 mail systemd[1]: openldap.service: Main process exited, code=exited, status=255/EXCEPTION Oct 05 07:33:43 mail systemd[1]: openldap.service: Failed with result 'exit-code'. Oct 05 07:33:43 mail systemd[1]: Failed to start OpenLDAP. Oct 05 07:38:22 mail systemd[1]: Starting OpenLDAP... so it worked likely without problems on the most current 2.6 commit at Oct 04 08:04:33 UTC. Note that the failing slapd does terminate before reading the configuration files with newfstatat(AT_FDCWD, "/etc/openldap/", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 newfstatat(AT_FDCWD, "/etc/openldap/", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f03c36d1000 openat(AT_FDCWD, "/etc/openldap//cn=config.ldif", O_RDONLY) = 9 newfstatat(9, "", {st_mode=S_IFREG|0600, st_size=817, ...}, AT_EMPTY_PATH) = 0 so it shall be irrelevant how MDB handles the data. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9932] New: Sync failing between two LDAP servers
by openldap-its＠openldap.org 13 Oct '22

13 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9932 Issue ID: 9932 Summary: Sync failing between two LDAP servers Product: OpenLDAP Version: 2.4.58 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: shikhar81(a)gmail.com Target Milestone: --- Hi Team, We have noticed a sync issue in our environment. We have two production servers namely A and B and two DR servers namely C and D. A and B are in bi-directional sync A and C are in bi-directional sync B and D are in bi-directional sync Since the last few days the sync between A and C and B and D has broken and we are unable to see any concrete error in logs Just to add here that server A and server B are in the same subnet and server C & server D are in a different subnet. However, this setup has been working fine since the last many years with no issues at all. Since the last few days the connection has broken as mentioned earlier. Now we also tried to initiate a sync between C and D (DR servers) which are in the same subnet. But still it is not syncing and we get a "no connection" error message in the logs after trying for 2-3 hrs. Can you please suggest what can be done here. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9928] New: ldap_search_ext_s always hangs on 2.6.3
by openldap-its＠openldap.org 12 Oct '22

12 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9928 Issue ID: 9928 Summary: ldap_search_ext_s always hangs on 2.6.3 Product: OpenLDAP Version: 2.6.3 Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: filipe.custodio(a)gmail.com Target Milestone: --- Created attachment 920 --> https://bugs.openldap.org/attachment.cgi?id=920&action=edit Minimal AD query that consistently hangs on ldap_search_ext_s call Dear Experts, When using ldap_search_ext_s() from libldap v2.6.3 to do a simple search on our production Windows Domain Controller, the client consistently hangs forever. Using ldap_search_ext() & ldap_result() also hangs after delivering the first information item. It seems the client is left waiting, not realising no more results are coming from the server. Using the development image from Oct. 9 2022, the ldap_search_ext_s() call works, although it gives an "Operations Error". Shall I deploy the new libldap from the development branch in our production environment to solve this problem or is there another way around the issue? Best regards, Filipe Custódio -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9919] New: The use of a separate section for cold code can cause linking issues on macOS
by openldap-its＠openldap.org 03 Oct '22

03 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9919 Issue ID: 9919 Summary: The use of a separate section for cold code can cause linking issues on macOS Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: mh-bcrayqnc(a)glandium.org Target Milestone: --- See e.g. https://github.com/llvm/llvm-project/issues/52767 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9365] New: Mem leaks with Æ-DIR providers
by openldap-its＠openldap.org 03 Oct '22

03 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9365 Issue ID: 9365 Summary: Mem leaks with Æ-DIR providers Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Created attachment 772 --> https://bugs.openldap.org/attachment.cgi?id=772&action=edit valgrind output on openSUSE Tumbleweed x86_64 An Æ-DIR installation with self-compiled OpenLDAP 2.4.53 on Debian (now buster) has memory leak issues on the Æ-DIR providers. The read-only consumers do not have this issue. The provider config is more complex with more overlays and more ACLs. In this production deployment slapd is automatically restarted (by monit) when memory consumption reaches 80%. Thus monitoring clearly shows a frequent saw tooth pattern. I've also tested on openSUSE Tumbleweed x86_64 with a RE24 build [1] by running slapd under control of valgrind for a couple of minutes continously sending simple bind operations (additional to the monitoring and other back-ground jobs running). Find valgrind output of my first attempt attached. Does that make sense at all? -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9923] New: extensible match ignored
by openldap-its＠openldap.org 28 Sep '22

28 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9923 Issue ID: 9923 Summary: extensible match ignored Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: francois(a)rcdevs.com Target Milestone: --- Hi, I'm trying to use a matching rule with slapd as a proxy in front of Active Directory with back-ldap The request is something similar to '(memberOf:1.2.840.113556.1.4.1941:=cn=gp1,o=Root)' It works if I use it directly on AD. Unfortunately, the request is ignored by slapd and not forwarded, I receive a "success" but the result is empty. The request is forwarded if I use something like this: '(memberOf=cn=gp1,o=Root)' Could it be possible to forward the request to the backend? slapd doesn't need to understand the meaning of the OID. slapd with matching rule: [2022-09-28 11:07:39] begin get_filter [2022-09-28 11:07:39] EXTENSIBLE [2022-09-28 11:07:39] daemon: activity on 1 descriptor [2022-09-28 11:07:39] end get_filter 0 [2022-09-28 11:07:39] filter: (?=undefined) [2022-09-28 11:07:39] attrs: dn [2022-09-28 11:07:39] conn=1000 op=1 SRCH base="o=root" scope=2 deref=0 filter="(?=undefined)" slapd without matching rule: [2022-09-28 11:07:47] begin get_filter [2022-09-28 11:07:47] EQUALITY [2022-09-28 11:07:47] get_ava: unknown attributeType memberOf [2022-09-28 11:07:47] [2022-09-28 11:07:47] end get_filter 0 [2022-09-28 11:07:47] daemon: epoll: listen=7 active_threads=0 tvp=NULL [2022-09-28 11:07:47] daemon: epoll: listen=8 active_threads=0 tvp=NULL [2022-09-28 11:07:47] filter: (?memberOf=cn=gp1,o=Root) [2022-09-28 11:07:47] attrs: dn [2022-09-28 11:07:47] conn=1001 op=1 SRCH base="o=root" scope=2 deref=0 filter="(?memberOf=cn=gp1,o=Root)" searchrequest dump: 0000 30 56 02 01 02 63 51 04 06 6f 3d 72 6f 6f 74 0a 0V...cQ..o=root. 0010 01 02 0a 01 00 02 01 00 02 01 00 01 01 00 a9 32 ...............2 0020 81 17 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 ..1.2.840.113556 0030 2e 31 2e 34 2e 31 39 34 31 82 08 6d 65 6d 62 65 .1.4.1941..membe 0040 72 4f 66 83 0d 63 6e 3d 67 70 31 2c 6f 3d 52 6f rOf..cn=gp1,o=Ro 0050 6f 74 30 04 04 02 64 6e ot0...dn -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9878] New: test043 failures in 2.5/2.6
by openldap-its＠openldap.org 26 Sep '22

26 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9878 Issue ID: 9878 Summary: test043 failures in 2.5/2.6 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: --- With test043 update for ITS#9823, we manage to introduce a scenario where the server is completely idle except for a runqueue change. This is partly identical with ITS#9642 and a similar approach would work. Except that changes our module facing ABI so might not be something we can backport. For the streams we can't, we might have to change the test to make the server not idle. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9922] New: Uninitialized value reading in clients/tools/common.c:tool_bind()
by openldap-its＠openldap.org 26 Sep '22

26 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9922 Issue ID: 9922 Summary: Uninitialized value reading in clients/tools/common.c:tool_bind() 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: --- One possible flow in https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm… is: int err; if ( result ) { rc = ldap_parse_result( ld, result, &err, &matched, &info, &refs, &ctrls, 1 ); if ( rc != LDAP_SUCCESS ) { tool_perror( "ldap_bind parse result", rc, NULL, matched, info, refs ); tool_exit( ld, LDAP_LOCAL_ERROR ); } } if ( err != LDAP_SUCCESS … When result is NULL, err is not initialized, and the last line reads uninitialized value. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9030] Use sys/cachectl.h rather than asm/cachectl.h on mips
by openldap-its＠openldap.org 26 Sep '22

26 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9030 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |0.9.30 --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE0.9: • 4bb20ed0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9030] Use sys/cachectl.h rather than asm/cachectl.h on mips
by openldap-its＠openldap.org 22 Sep '22

22 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9030 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- patched in mdb.master ; mdb.master3 ; mdb.RE/0.9 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9918] New: Can't log on git.openldap.org
by openldap-its＠openldap.org 22 Sep '22

22 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9918 Issue ID: 9918 Summary: Can't log on git.openldap.org Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: mh-bcrayqnc(a)glandium.org Target Milestone: --- Followup for https://github.com/LMDB/lmdb/pull/23#issuecomment-1254532527. I created the account in February, apparently, with login glandium, but I'm not sure what email. Presumably the one from this bugzilla account. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9524] New: Removing last entry in database triggers MDB_PROBLEM
by openldap-its＠openldap.org 21 Sep '22

21 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9524 Issue ID: 9524 Summary: Removing last entry in database triggers MDB_PROBLEM Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- With a fresh database, if you have have an open read transaction, and you create a new entry in a write transaction and commit it, and then create a new transaction and delete that entry, when you commit, it will return an MDB_PROBLEM from approximately line 4408 from the mt_loose_count/dirty_list check. This seems to occur on mdb.master3, but not mdb.master. Here is a minimal example/test-case of how to reproduce: MDB_env* env; mdb_env_create(&env); int rc, flags = 0; mdb_env_open(env, "test", flags, 0664); MDB_txn* readonly_txn; mdb_txn_begin(env, nullptr, MDB_RDONLY, &readonly_txn); MDB_txn* txn; MDB_dbi dbi; mdb_txn_begin(env, nullptr, 0, &txn); mdb_dbi_open(txn, nullptr, MDB_CREATE, &dbi); MDB_val val; val.mv_data = (void*) "test"; val.mv_size = 4; mdb_put(txn, dbi, &val, &val, 0); mdb_txn_commit(txn); mdb_txn_begin(env, nullptr, 0, &txn); mdb_del(txn, dbi, &val, nullptr); rc = mdb_txn_commit(txn); // this returns MDB_PROBLEM (let me know if this should be submitted differently) -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9910] New: undefined MDB_FDATASYNC in mdb.master3 on macOs
by openldap-its＠openldap.org 21 Sep '22

21 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9910 Issue ID: 9910 Summary: undefined MDB_FDATASYNC in mdb.master3 on macOs Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: info(a)parlepeuple.fr Target Milestone: --- Created attachment 912 --> https://bugs.openldap.org/attachment.cgi?id=912&action=edit patch I am using the mdb.master3 branch which contains the encryption codebase. While testing on macOS, compilation fails with "undefined MDB_FDATASYNC" This is because commit #d85fe32 https://git.openldap.org/openldap/openldap/-/commit/d85fe32dab55b88cec25fc7… introduced a bug in the sense that the #elif on line 167 is not executed if the previous #elif is true. So when defined(__APPLE__) && !defined(MDB_USE_ROBUST) is true, the following #elif is skipped. But this seconf @elif is essential, as it defines MDB_FDATASYNC Proposed patch: --- libraries/liblmdb/mdb.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 5bdec70..b54c8ae 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -164,9 +164,10 @@ typedef SSIZE_T ssize_t; #if defined(__FreeBSD__) && defined(__FreeBSD_version) && __FreeBSD_version >= 1100110 # define MDB_USE_POSIX_MUTEX 1 # define MDB_USE_ROBUST 1 -#elif defined(__APPLE__) && !defined(MDB_USE_ROBUST) -# define MDB_USE_POSIX_SEM 1 #elif defined(__APPLE__) || defined (BSD) || defined(__FreeBSD_kernel__) +# if defined(__APPLE__) && !defined(MDB_USE_ROBUST) +# define MDB_USE_POSIX_SEM 1 +# endif # if !(defined(MDB_USE_POSIX_MUTEX) || defined(MDB_USE_POSIX_SEM)) # define MDB_USE_SYSV_SEM 1 # endif -- -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9911] New: MDB_PROBLEM: Unexpected problem - txn should abort, because of mdb_page_loose
by openldap-its＠openldap.org 21 Sep '22

21 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9911 Issue ID: 9911 Summary: MDB_PROBLEM: Unexpected problem - txn should abort, because of mdb_page_loose Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: info(a)parlepeuple.fr Target Milestone: --- In mdb.master3, when running some test suite, the transaction commit fails with MDB_PROBLEM: Unexpected problem - txn should abort The operation that where executed on a blank database: mdb_env_create mdb_env_open with CREATE mode mdb_txn_begin RW mdb_put one key value mdb_txn_commit mdb_txn_begin RW mdb_drop mdb_txn_commit This last commit fails with : MDB_PROBLEM: Unexpected problem - txn should abort My investigation shows that the lines 4401-4403 are triggered: if ((unsigned)txn->mt_loose_count != txn->mt_u.dirty_list[0].mid) { rc = MDB_PROBLEM; /* mt_loose_pgs does not match dirty_list */ goto fail; } And this is because of the commit #12ee1a2 "Use mdb_page_loose() more" https://git.openldap.org/openldap/openldap/-/commit/12ee1a2d7104616ccb812db… that does a mdb_page_loose instead of a mdb_midl_append on line 9496. Reverting this commit solves the problem. This commit seems to be a non essential optimization. But you will see into it as i am not so familiar with the refactoring that Hallvard Furuseth did back in July 2017. It would be nice to have an official fix from you, instead of this revert I did temporally to be able to continue working. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

Using self signed certificate causes ldap_sasl_bind_s() error
by rinchive＠gmail.com 20 Sep '22

20 Sep '22

Hi. I'm trying to use C code of your gitlab repository to make a program that can bind to remote LDAP server. I have some problems with using self signed certificate in openldap server. When I try to connect to remote LDAP server with SSL connection, ldap_sasl_bind_s return this error : "Can't contact LDAP server (-1) additional info: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain) " At the same time, server prints like this : 632973de conn=1018 fd=12 ACCEPT from IP=172.17.0.1:57250 (IP=0.0.0.0:636) TLS: can't accept: A TLS fatal alert has been received.. 632973de conn=1018 fd=12 closed (TLS negotiation failure) I use docker image to build an openldap server for test and made my own CA certificates, server's private key and certificate for TLS connection. On client program side, I set some options related to TLS connection. I set LDAP_OPT_X_TLS_REQUIRE_CERT to LDAP_OPT_X_TLS_NEVER, and set LDAP_OPT_X_TLS_CACERTDIR, LDAP_OPT_X_TLS_CACERTFILE to the path that server's CA certificate file is stored. I think I set all options that I can do on client side, but client always verify server's certificate and return "certificate verify failed (self signed certificate in certificate chain)" this error. It is okay to bind without TLS negotiation on client program. Also I made a connection with the server using LDAPAdmin which is windows ldap client program and it makes TLS connection successfully. Is there other option or some codes to be executed to make a secure connection using self signed certificate? I've been struggling with this error for a couple of weeks and not able to find a solution. Can I make a TLS connection with the server that uses the self-signed certificate?

1 0

[Issue 8912] incorrect rootDSE (namingContexts)
by openldap-its＠openldap.org 15 Sep '22

15 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=8912 --- Comment #8 from Cliff <cwheat(a)sterlingandzoe.info> --- Thank you for the reply and my apologies for the lack of clarity. Upon further testing, I was unable to reproduce the behavior using a command line application, ldapsearch. I should have done that before submitting the bug. If you have been assigned this issue then please close it. I hope this is more clear: When attempting to display all of the subordinate partitions in the root partition I was only able to see a portion. Those displayed results were all of the same naming context, relative DN c=* or o=*. There is some form of filtering done by the LDAPBrowser GUI. This does not happen using ldapsearch. The problem is not in slapd as I initially thought. Thanks again for your reply. --Cliff On Monday, September 12, 2022 at 12:44:54 PM EDT, <openldap-its(a)openldap.org> wrote: https://bugs.openldap.org/show_bug.cgi?id=8912 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Cliff from comment #6) > On Fedora Core 36, > @(#) $OpenLDAP: slapd 2.6.2 (Aug 15 2022 00:00:00) $ > openldap > Included static backends: > config > ldif > monitor > mdb > using LDAP Browser\Editor v2.8.1: > > While attempting to add subordinate naming contexts off of base DN "" > (RootDSE), slapd will only show such subordinate naming contexts if they are > of the same RDN attribute. For instance, using all of FC36's trusted CA > certificates DN, which boil down to those based at c=?, or o=?, only those > of the same attribute will display as subordinates to "". I either get all > c= or o=, but not both. The subordinate naming context attribute that comes > in the configuration file determines which attribute will be shown. Hello, I honestly have no idea what you're trying to say here, but it seems thoroughly unrelated to this issue. If you feel that you've found an actual bug, then you should file something new with complete reproduction steps. If you're having issues understanding how to execute queries to OpenLDAP correctly please email the openldap-technical list. Regards, Quanah -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9339] New: Add syncrepl status in cn=monitor
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9339 Issue ID: 9339 Summary: Add syncrepl status in cn=monitor Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Patch coming to expose some consumer state in cn=monitor Sample entry: # Consumer 001, database 2, databases, monitor dn: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor objectClass: olmSyncReplInstance structuralObjectClass: olmSyncReplInstance cn: Consumer 001 creatorsName: modifiersName: createTimestamp: 20200906160447Z modifyTimestamp: 20200906160447Z olmSRProviderURIList: ldap://localhost:9011/ olmSRIsConnected: TRUE olmSRSyncPhase: Persist olmSRLastConnect: 20200906160448Z olmSRLastContact: 20200906160453Z olmSRLastCookieRcvd: rid=001,sid=001,csn=20200906160453.039573Z#000000#001#000 000 olmSRLastCookieSent: rid=001,sid=002,csn=20200906160447.723677Z#000000#001#000 000 entryDN: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor subschemaSubentry: cn=Subschema hasSubordinates: FALSE -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9853] New: lastbind-precision conversion fails from slapd.conf to cn=config
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9853 Issue ID: 9853 Summary: lastbind-precision conversion fails from slapd.conf to cn=config Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When converting a slapd.conf file to cn=config, the "lastbind-precision" value is not preserved. slapd.conf: lastbind-precision 300 cn=config value: olcLastBindPrecision: 0 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9437] New: Add OTP module to core
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9437 Issue ID: 9437 Summary: Add OTP module to core Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Symas will contribute its OTP module for OpenLDAP 2.5 as a core overlay -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 6035] slapd requires restart after modifying olcAuthzRegexp
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=6035 --- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • f3ed13fa by Ondřej Kuzník at 2022-09-01T10:09:27+01:00 ITS#6035 Plug olcAuthIDRewrite cn=config leak RE26: • d598f537 by Ondřej Kuzník at 2022-09-12T20:43:29+00:00 ITS#6035 Plug olcAuthIDRewrite cn=config leak RE25: • 1b80eb42 by Ondřej Kuzník at 2022-09-12T20:43:41+00:00 ITS#6035 Plug olcAuthIDRewrite cn=config leak -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9817] New: rwm overlay : Issue with DN containing special characters
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9817 Issue ID: 9817 Summary: rwm overlay : Issue with DN containing special characters Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: thierry.pubellier(a)paris.fr Target Milestone: --- Hi, I'm using rwn to select the database useg for bind operations based on the result of a rewriteMap requets. Sample configuration in global section : #Rewrite Map to request a remote server rwm-rewriteMap ldap checkEntry "ldap://10.1.2.3/ou=users,dc=paris,dc=local?dn?sub" binddn="cn=myuser,ou=users,dc=paris,dc=local" credentials="XXX" # Backing up original DN rwm-rewriteRule ".+" "${&binddn($0)}$0" ":" # Contructing LDAP Filter for remote search. Combined with a rewrite Map, the requested DN is returned if there is a match. rwm-rewriteRule ".+" "(&(!(description=TEST))(distinguishedName=$0))" ":" # If filter matches, end of rewriting. Going to 'dc=paris,dc=local' database rwm-rewriteRule ".+" "${checkIfPasswordExpiredDN($0)}" ":@I" # Otherwise, restoring the original DN. rwm-rewriteRule ".+" "${*binddn}" ":" # And final DN massaging from "dc=paris,dc=local" to "dc=paris,dc=local2" database rwm-rewriteRule "(.+,)?ou=users,dc=paris,dc=local$" "$1ou=users,dc=paris,dc=local2" ":@" Everything goes fine until I use DN with special characters, like ',' or '['. For example : 'cn=Pubellier\, Thierry (TEST),ou=users,dc=paris,dc=local' In this case, the rwm-rewriteRule contructs a LDAP filter with incorrect syntax, as special caracters are not being escaped. I have to use some ugly tricks to escape these caracters, as shown below : #Rewrite Map to request a remote server rwm-rewriteMap ldap checkEntry "ldap://10.1.2.3/ou=users,dc=paris,dc=local?dn?sub" binddn="cn=myuser,ou=users,dc=paris,dc=local" credentials="XXX" # Backing up original DN rwm-rewriteRule ".+" "${&binddn($0)}$0" ":" # Rewriting for ',' rwm-rewriteRule "(.+).\2C(.+)" "$1\\,$2" # Adding a special '#' (asserting it in none of my DNs) suffix for special characters, in order to escape them without looping forever rwm-rewriteRule "(.*)([)*(\\])([^#].*|$)" "$1$2#$3" # Escaping of special characters with dedicated '#' suffix, avoiding infinite loops rwm-rewriteRule "(.*)([)*(\\])#(.*)" "$1\\$2$3" # Contructing LDAP Filter for remote search. Combined with a rewrite Map, the requested DN is returned if there is a match. rwm-rewriteRule ".+" "(&(!(description=TEST))(distinguishedName=$0))" ":" # If filter matches, end of rewriting. Going to 'dc=paris,dc=local' database rwm-rewriteRule ".+" "${checkIfPasswordExpiredDN($0)}" ":@I" # Otherwise, restoring the original DN. rwm-rewriteRule ".+" "${*binddn}" ":" # And final DN massaging from "dc=paris,dc=local" to "dc=paris,dc=local2" database rwm-rewriteRule "(.+,)?ou=users,dc=paris,dc=local$" "$1ou=users,dc=paris,dc=local2" ":@" Could there be a way to integrate the ldap escape mechanism when making an variable assignment (like using a '#' character in place of the usual '&') ? Thanks by advance, Best regards, Thierry -- You are receiving this mail because: You are on the CC list for the issue.

1 21

[Issue 9438] New: Add remoteauth overlay to core
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9438 Issue ID: 9438 Summary: Add remoteauth overlay to core Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Symas will contribute its remoteauth overlay for OpenLDAP 2.5 as a core overlay -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 8912] incorrect rootDSE (namingContexts)
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=8912 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Cliff from comment #6) > On Fedora Core 36, > @(#) $OpenLDAP: slapd 2.6.2 (Aug 15 2022 00:00:00) $ > openldap > Included static backends: > config > ldif > monitor > mdb > using LDAP Browser\Editor v2.8.1: > > While attempting to add subordinate naming contexts off of base DN "" > (RootDSE), slapd will only show such subordinate naming contexts if they are > of the same RDN attribute. For instance, using all of FC36's trusted CA > certificates DN, which boil down to those based at c=?, or o=?, only those > of the same attribute will display as subordinates to "". I either get all > c= or o=, but not both. The subordinate naming context attribute that comes > in the configuration file determines which attribute will be shown. Hello, I honestly have no idea what you're trying to say here, but it seems thoroughly unrelated to this issue. If you feel that you've found an actual bug, then you should file something new with complete reproduction steps. If you're having issues understanding how to execute queries to OpenLDAP correctly please email the openldap-technical list. Regards, Quanah -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8912] incorrect rootDSE (namingContexts)
by openldap-its＠openldap.org 09 Sep '22

09 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=8912 --- Comment #6 from Cliff <cwheat(a)sterlingandzoe.info> --- On Fedora Core 36, @(#) $OpenLDAP: slapd 2.6.2 (Aug 15 2022 00:00:00) $ openldap Included static backends: config ldif monitor mdb using LDAP Browser\Editor v2.8.1: While attempting to add subordinate naming contexts off of base DN "" (RootDSE), slapd will only show such subordinate naming contexts if they are of the same RDN attribute. For instance, using all of FC36's trusted CA certificates DN, which boil down to those based at c=?, or o=?, only those of the same attribute will display as subordinates to "". I either get all c= or o=, but not both. The subordinate naming context attribute that comes in the configuration file determines which attribute will be shown. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9905] New: The test case 043 execution failed
by openldap-its＠openldap.org 05 Sep '22

05 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9905 Issue ID: 9905 Summary: The test case 043 execution failed Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: 1010881517(a)qq.com Target Milestone: --- Test case 043 failed after I added #9823 pr to my openldap-2.6.0. Some logs may be useful to you. >>>>> Starting test043-delta-syncrepl for mdb... running defines.sh Starting provider slapd on TCP/IP port 9011... Using ldapsearch to check that provider slapd is running... Using ldapadd to create the context prefix entries in the provider... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the provider directory... Waiting 7 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that provider slapd is running... Using ldapmodify to modify provider directory... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... Using ldapsearch to read all the entries from the consumer... Filtering provider results... Filtering consumer results... Comparing retrieved entries from provider and consumer... Stopping consumer to test recovery... Modifying more entries on the provider... Restarting consumer... Waiting 7 seconds for syncrepl to receive changes... Try updating the consumer slapd... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... Using ldapsearch to read all the entries from the consumer... Filtering provider results... Filtering consumer results... Comparing retrieved entries from provider and consumer... Stopping consumer to test recovery after logpurge expired... Modifying even more entries on the provider... Configuring logpurge of 1 second... Waiting 4 seconds for accesslog to be purged... Using ldapsearch to check if accesslog is empty... Restarting consumer... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... Using ldapsearch to read all the entries from the consumer... Filtering provider results... Filtering consumer results... Comparing retrieved entries from provider and consumer... test failed - provider and consumer databases differ >>>>> Failed test043-delta-syncrepl for mdb after 0 seconds (exit 1) -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9358] New: back-mdb may return accesslog entries out of order
by openldap-its＠openldap.org 01 Sep '22

01 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9358 Issue ID: 9358 Summary: back-mdb may return accesslog entries out of order Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- back-mdb will usually return search entries in entryID order, but may do a dn traversal instead if the count of children is smaller than the count of search filter candidates. The RDNs are sorted in length order, not lexical order. For accesslog, all RDNs are of equal length but if they have trailing zeroes, the generalizedTime normalizer truncates them. Changing their lengths causes accesslog's timestamp-based RDNs to sort in the wrong order. The least intrusive fix is to override the syntax/normalizer for reqStart and reqEnd attributes to not truncate trailing zeroes. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8064] SIGSEGV in monitor-shutdown code
by openldap-its＠openldap.org 01 Sep '22

01 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=8064 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9906 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9903] New: Broken link and images in Powered By page
by openldap-its＠openldap.org 31 Aug '22

31 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9903 Issue ID: 9903 Summary: Broken link and images in Powered By page Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: jkirkwood(a)kclinfo.com Target Milestone: --- In the page https://www.openldap.org/powered.html (linked from the phrase 'This site is powered by open source software.' at the bottom of the home page) 1) the link to 'Website Meta Language' is broken - it may have moved to https://thewml.github.io ? 2) the links to the logo images are broken - https://www.openldap.org/icons/logo/wml.gif - https://www.openldap.org/icons/logo/freebsd.gif - https://www.openldap.org/icons/logo/apache.gif I randomly noticed this - not breaking anything I'm aware of, so possibly only a cosmetic issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9516] New: Argon2 configuration parameters with slappasswd
by openldap-its＠openldap.org 23 Aug '22

23 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9516 Issue ID: 9516 Summary: Argon2 configuration parameters with slappasswd Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gilbert.kowarzyk(a)servicenow.com Target Milestone: --- It is currently possible to generate an Argon2 hash using slappasswd as follows: slappasswd -h {ARGON2} -o module-load=pw-argon2 However, I believe that it is currently not possible to provide Argon2 configuration values for parameters "m", "t", and "p" when using slappasswd. If it is currently possible to provide these config parameters when using slappasswd, please add documentation for how to do so. Thanks in advance! -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9889] New: Error while installation Openldap 2.5.9
by openldap-its＠openldap.org 15 Aug '22

15 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9889 Issue ID: 9889 Summary: Error while installation Openldap 2.5.9 Product: OpenLDAP Version: 2.5.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: vmaidarkar(a)gmail.com Target Milestone: --- Hi Team, While installing OpenLDAP v2.5.9 we are getting following error "Clould not locate TLS/SSL package. Error:- checking openssl/ssl.h usability... no checking openssl/ssl.h presence... no checking for openssl/ssl.h... no configure:error: Could not locate TLS/SSL package Kindly suggest to resolve this issue. Thanks. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9891] New: The test case execution time is too long.
by openldap-its＠openldap.org 08 Aug '22

08 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9891 Issue ID: 9891 Summary: The test case execution time is too long. Product: OpenLDAP Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: 1010881517(a)qq.com Target Milestone: --- OpenLDAP test cases use a large amount of sleep. As a result, it takes a long time to execute all test cases. Is there any way to shorten the time? -- You are receiving this mail because: You are on the CC list for the issue.

2 8

[Issue 9896] New: Error: Could not locate TLS/SSL package
by openldap-its＠openldap.org 08 Aug '22

08 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9896 Issue ID: 9896 Summary: Error: Could not locate TLS/SSL package Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: vmaidarkar(a)gmail.com Target Milestone: --- Created attachment 909 --> https://bugs.openldap.org/attachment.cgi?id=909&action=edit Error: Could not locate TLS/SSL package Hi Team, I'm getting the below error while installing OpenLDAP 2.5.13 on CentOS 7.9 & OpenSSL 1.1.1g & attaching config.log file. checking for openssl/ssl.h... yes checking for SSL_export_keying_material_early in -lssl... no configure: error: Could not locate TLS/SSL package Kindly suggest how to fix this issue. Thanks, Vijay -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9893] New: Unable to create ldap object with same unique value as deleted object
by openldap-its＠openldap.org 08 Aug '22

08 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9893 Issue ID: 9893 Summary: Unable to create ldap object with same unique value as deleted object Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: curtis.ruck+github(a)gmail.com Target Milestone: --- I have a unique overlay that is trying to ensure uniqueness of two attributes, mail and uid. My configdir config for my mdb database: dn: olcOverlay={1}unique objectClass: olcUniqueConfig objectClass: olcOverlayConfig olcOverlay: unique olcUniqueURI: ldap://?mail?sub olcUniqueURI: ldap://?uid?sub structuralObjectClass: olcUniqueConfig If I delete a user, and then go to recreate it, I get this error: msgtype 105, error 19, constraint violation non-unique attributes found with (|(uid=jdoe)(givenName=John)(sn=Doe)(cn=John Doe)(mail=john(a)example.com)(userPassword=<password>)(objectClass=inetOrgPerson)) Somehow I believe the unique index structure is broken. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9890] New: Core is seen while reboot for RHEL_8_4_X86_64
by openldap-its＠openldap.org 03 Aug '22

03 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9890 Issue ID: 9890 Summary: Core is seen while reboot for RHEL_8_4_X86_64 Product: OpenLDAP Version: 2.4.59 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: sunil.ece.126(a)gmail.com Target Milestone: --- Hi, I am seeing below core while using openLdap 2.4.59. We are using openLdap in our application as stack to initiate the connection towards ldapServer. Current I am using RHEL_8_4_X86_64. Core is seen whenever system is going for reboot. Let me know if more information is required. (gdb) bt #0 0x00007ff94be7d998 in vtable for {}cxxabiv1::{_}_si_class_type_info () from /lib64/libstdc++.so.6 #1 0x00007ff9520296cc in ManagedObjectList* ManagedObject::findMOListByKey<MOID>(MOID const&) const () from /usr/IMS/current/bin/libMX.so.0 #2 0x00007ff9520287a5 in ManagedObject::findObjectById(MOID const&) const () from /usr/IMS/current/bin/libMX.so.0 #3 0x00007ff952029fa9 in SignalInstaller::signalAction(int, siginfo_t*, void*) () from /usr/IMS/current/bin/libMX.so.0 #4 <signal handler called> #5 memfence_check (ptr=0x7fffffff00000000, size=0x0) at src/tcmalloc.cc:294 #6 0x00007ff94c72f90d in memfence_check_and_free (ptr=<optimized out>, size=size@entry=0x0) at src/tcmalloc.cc:307 #7 0x00007ff94c73dfe4 in free_fast_path (ptr=<optimized out>) at src/tcmalloc.cc:2142 #8 tc_free (ptr=<optimized out>) at src/tcmalloc.cc:2149 #9 0x00007ff949d3b0ce in ldap_int_destroy_global_options () from /lib64/libldap-2.4.so.2 #10 0x00007ff9528cfc96 in _dl_fini () from /lib64/ld-linux-x86-64.so.2 #11 0x00007ff94b1d0b0c in __run_exit_handlers () from /lib64/libc.so.6 #12 0x00007ff94b1d0c40 in exit () from /lib64/libc.so.6 #13 0x00007ff94b1ba49a in __libc_start_main () from /lib64/libc.so.6 #14 0x0000000000427b6e in _start () -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9885] New: Error while compilation of Openldap 2.5.9
by openldap-its＠openldap.org 22 Jul '22

22 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9885 Issue ID: 9885 Summary: Error while compilation of Openldap 2.5.9 Product: OpenLDAP Version: 2.5.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: rekha.shivsan(a)gmail.com Target Milestone: --- Created attachment 908 --> https://bugs.openldap.org/attachment.cgi?id=908&action=edit Error while compilation Hi, We are trying to install Openldap v2.5.9. While running the make command we are seeing below error. ./.libs/libldap.so: undefined reference to `BIO_meth_set_read' ./.libs/libldap.so: undefined reference to `BIO_get_data' ./.libs/libldap.so: undefined reference to `BIO_meth_set_write' ./.libs/libldap.so: undefined reference to `OPENSSL_sk_value' ./.libs/libldap.so: undefined reference to `BIO_meth_set_ctrl' ./.libs/libldap.so: undefined reference to `OPENSSL_sk_new_null' ./.libs/libldap.so: undefined reference to `BIO_meth_set_gets' ./.libs/libldap.so: undefined reference to `BIO_meth_set_create' ./.libs/libldap.so: undefined reference to `SSL_CTX_set_ciphersuites' ./.libs/libldap.so: undefined reference to `BIO_meth_set_puts' ./.libs/libldap.so: undefined reference to `BIO_meth_free' ./.libs/libldap.so: undefined reference to `BIO_meth_new' ./.libs/libldap.so: undefined reference to `OPENSSL_sk_push' ./.libs/libldap.so: undefined reference to `EVP_MD_CTX_new' ./.libs/libldap.so: undefined reference to `X509_NAME_get0_der' ./.libs/libldap.so: undefined reference to `BIO_set_init' ./.libs/libldap.so: undefined reference to `OPENSSL_sk_num' ./.libs/libldap.so: undefined reference to `SSL_CTX_up_ref' ./.libs/libldap.so: undefined reference to `OPENSSL_init_ssl' ./.libs/libldap.so: undefined reference to `ASN1_STRING_get0_data' ./.libs/libldap.so: undefined reference to `TLS_method' ./.libs/libldap.so: undefined reference to `EVP_MD_CTX_free' ./.libs/libldap.so: undefined reference to `SSL_CTX_set_options' ./.libs/libldap.so: undefined reference to `SSL_set_ciphersuites' ./.libs/libldap.so: undefined reference to `BIO_meth_set_destroy' ./.libs/libldap.so: undefined reference to `SSL_session_reused' ./.libs/libldap.so: undefined reference to `X509_get_X509_PUBKEY' ./.libs/libldap.so: undefined reference to `OPENSSL_sk_free' ./.libs/libldap.so: undefined reference to `BIO_set_data' ./.libs/libldap.so: undefined reference to `SSL_CTX_clear_options' collect2: error: ld returned 1 exit status Complete error logs are attached " OpenLdap 2.5.9_error.txt". Could you please help to resolve this issue. Thanks. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9873] New: idle timeout by backends close connections
by openldap-its＠openldap.org 18 Jul '22

18 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9873 Issue ID: 9873 Summary: idle timeout by backends close connections Product: OpenLDAP Version: 2.6.2 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ettorevi(a)gmail.com Target Milestone: --- Hi, making searches through lloadd to a bunch of backends returns weird results Sometimes I get: | ldap_bind: Other (e.g., implementation specific) error (80) | additional info: connection to the remote server has been severed Others ldap_result: Can't contact LDAP server (-1) due to an idle_timeout from the backend in the middle of the search, in a non deterministic way. If I search directly on the backends everything works ldapsearch -x -Hldaps://lloadd.server 'objectClass=*' -w pwd [...] # numResponses: 9620 # numEntries: 9620 ldap_result: Can't contact LDAP server (-1) lloadd compiled standalone from 2.6.2 with: --enable-balancer=yes --enable-syslog --enable-debug --enable-slapd=no Backends are older, 2.4.49+dfsg-2ubuntu1.9 from Ubuntu 20.04 Any hints? Thank you -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9846] New: Provide ppm v2.2
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9846 Issue ID: 9846 Summary: Provide ppm v2.2 Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Provide the new release of ppm: v2.2: - implement a maximum number of characters for each class #18 - upgrade documentation for new olcPPolicyCheckModule in OpenLDAP 2.6 #30 - Make one unique code of development for 2.5 and 2.6 OpenLDAP versions #35 - fix segmentation fault in ppm_test #36 - various minor fixes and optimizations See: https://github.com/ltb-project/ppm/milestone/5 I am going to propose a MR soon. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9856] New: Lloadd doesn't tag Notice of Disconnection responseName
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9856 Issue ID: 9856 Summary: Lloadd doesn't tag Notice of Disconnection responseName Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- The responseName field in Notice of Disconnection is being tagged as a generic octet string, where RFC4511 marks it with "responseValue [11] OCTET STRING OPTIONAL". Fix is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9858] New: cn=config replication refresh breaks mdb database
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9858 Issue ID: 9858 Summary: cn=config replication refresh breaks mdb database Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- working in an environment with the following layout: Config node -> This node contains the cn=config databases for consumers in one tree and providers in another tree. provider nodes -> Pull their configuration from the config node via standard syncrepl consumer nodes -> Pull their configuration from the config node via standard syncrepl This worked fine with OpenLDAP 2.4. With 2.6, using the same cn=config configuration, slapd will segfault if the cn=config db is put through a REFRESH sequence. I've ruled out syncprov as an issue as I removed the syncprov configuration from the consumer nodes entirely and it still occurs (I was thinking perhaps it was the syncprov checkpoint at shutdown). At this point I can reproduce this trivially 100% of the time simply by having a node REFRESH cn=config. Once the REFRESH has occurred, slapd will continue running. However the next time it is stopped/started it will SEGV on startup. It is usually possible to use slapcat to extract the MDB database and rebuild it, at which point slapd will start again. A couple of times I was only able to extract a portion of the database using slapcat (70MB of 650MB). -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9855] New: Implement a module to enable case-insensitive Boolean values
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9855 Issue ID: 9855 Summary: Implement a module to enable case-insensitive Boolean values Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- The module, when loaded from slapd.conf, will allow for values such as true, false and True, False, to be accepted by the server -- You are receiving this mail because: You are on the CC list for the issue.

1 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs