- openldap-bugs - openldap.org

[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 9884] New: Document "set" patterns in ACLs
by openldap-its＠openldap.org 25 Jul '22

25 Jul '22

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

1 2

[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

[Issue 9850] New: slapd-watcher ignores sids when only 1 server is specified
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9850 Issue ID: 9850 Summary: slapd-watcher ignores sids when only 1 server is specified Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When only 1 URL is provided, it always uses only a contextCSN with sid=0. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 7165] Killing slap tools breaks the running mdb
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=7165 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 9865] New: slapd-watcher: support for glue
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9865 Issue ID: 9865 Summary: slapd-watcher: support for glue Product: OpenLDAP Version: unspecified 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: --- When operating on glued backends, the DB where entry counts need to be monitored may be different from where the contextCSN updates occur. Add a "-c" option to allow specifying the contextCSN baseDN, separate from the main "-b" baseDN. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9872] New: slapd-ldap(5) man page missing bold tag on authz parameter
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9872 Issue ID: 9872 Summary: slapd-ldap(5) man page missing bold tag on authz parameter Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The slapd-ldap(5) man page is missing a bold tag on the authz configuration parameter. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9864] New: One-time leaks in accesslog
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9864 Issue ID: 9864 Summary: One-time leaks in accesslog Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: minor Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- In tool mode, the accesslog's configured logdb suffix isn't freed. It's normally freed by the db_open handler but in tool mode the overlay never actually gets opened. Also due to 414866b8889 ITS#9580, li_sids can leak when replacing mincsn. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 8882] Empty Directory String Overlay
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=8882 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 9867] New: syncprov leak on early Abandons
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9867 Issue ID: 9867 Summary: syncprov leak on early Abandons Product: OpenLDAP Version: unspecified 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: --- The baseDN found by syncprov_findbase() can be leaked if an Abandon or error occurs early during psearch processing. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9871] New: bind operations on relay entries cause slapd to segfault with rwm and ppolicy enabled
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9871 Issue ID: 9871 Summary: bind operations on relay entries cause slapd to segfault with rwm and ppolicy enabled Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: subbarao(a)computer.org Target Milestone: --- On 2.5.12, slapd crashes during bind operations on relay entries with rwm and ppolicy both enabled. A simple way to reproduce this issue is to edit tests/scripts/relay and tests/data/slapd-relay.conf as follows, and then run test030-relay. I think this issue is the same as ITS#7966 reported in 2014. --- tests/scripts/relay.orig 2022-05-04 07:57:30.000000000 -0700 +++ tests/scripts/relay 2022-06-23 17:16:42.020652093 -0700 @@ -356,6 +356,16 @@ exit 1 fi +$LDAPADD -D "$MANAGERDN" -H $URI1 -w $PASSWD <<EOF > /dev/null 2>&1 +dn: cn=ppolicy,dc=example,dc=com +objectClass: top +objectClass: device +objectClass: pwdPolicy +cn: ppolicy +pwdMinLength: 5 +pwdAttribute: userPassword +EOF + BASEDN="o=Example,c=US" echo "Changing password to database \"$BASEDN\"..." $LDAPPASSWD -H $URI1 -D "cn=Manager,$BASEDN" -w $PASSWD \ --- tests/data/slapd-relay.conf.orig 2022-05-04 07:57:30.000000000 -0700 +++ tests/data/slapd-relay.conf 2022-06-23 16:57:15.184456120 -0700 @@ -31,6 +31,8 @@ #metamod#moduleload back_meta.la #rwmmod#modulepath ../servers/slapd/overlays/ #rwmmod#moduleload rwm.la +#ppolicymod#modulepath ../servers/slapd/overlays/ +#ppolicymod#moduleload ppolicy.la ####################################################################### # database definitions @@ -46,6 +48,9 @@ #ndb#dbname db_1 #ndb#include @DATADIR@/ndb.conf +overlay ppolicy +ppolicy_default cn=ppolicy,dc=example,dc=com + database @RELAY@ suffix "o=Example,c=US" ### back-relay can automatically instantiate the rwm overlay -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9876] New: Coverity report on OpenLDAP libraries and client tools
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9876 Issue ID: 9876 Summary: Coverity report on OpenLDAP libraries and client tools Product: OpenLDAP Version: 2.6.2 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: --- Created attachment 906 --> https://bugs.openldap.org/attachment.cgi?id=906&action=edit Covscan report for OpenLDAP 2.6.2 I've got a report from our Coverity Scan system. It had a lot of false positives so I've filtered it a bit. Please, find below the report with only RESOURCE_LEAK, LOCK, and MISSING_LOCK issues. I think there are still some false positives left, but I hope it's worth checking by core OpenLDAP developers. The report: https://spichugi.fedorapeople.org/openldap-covscan-2.6.2.html Thank you! -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9866] New: delta-sync memleak on Adds
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9866 Issue ID: 9866 Summary: delta-sync memleak on Adds Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Due to the entry->e_name massaging in back-mdb/add.c (ITS#5326) syncrepl wasn't freeing the non-normalized DN as expected after add finished. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9840] New: Fix parallel build failures
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9840 Issue ID: 9840 Summary: Fix parallel build failures Product: OpenLDAP Version: 2.5.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: yi.zhao(a)windriver.com Target Milestone: --- Created attachment 899 --> https://bugs.openldap.org/attachment.cgi?id=899&action=edit 0001-ldif-filter-fix-parallel-build-failure.patch I found there are two parallel build errors for ldif-filter and libraries: ldif-filter: ld: cannot find slapd-common.o: No such file or directory libraries: ../../build/shtool mkdir -p TOPDIR/tmp-glibc/work/cortexa15t2hf-neon-wrs-linux-gnueabi/openldap/2.5.9-r0/image/usr/lib mkdir: cannot create directory 'TOPDIR/tmp-glibc/work/cortexa15t2hf-neon-wrs-linux-gnueabi/openldap/2.5.9-r0/image/usr/lib': File exists make[1]: *** [Makefile:288: install-local] Error 1 I have attached 2 patches to fix these issues. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9824] New: getting/setting LDAP_OPT_X_SASL_ options require call to ldap_initialize
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9824 Issue ID: 9824 Summary: getting/setting LDAP_OPT_X_SASL_ options require call to ldap_initialize Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: jay.hendren(a)colorado.edu Target Milestone: --- Originally filed against python-ldap: https://github.com/python-ldap/python-ldap/issues/468 Per "man 3 ldap_get_option", some options can be set globally while others require an initialized LDAP struct: > These routines provide access to options stored either in a LDAP handle or as global options, where applicable. However, "where applicable" doesn't seem to have any further clarification. In particular, getting or setting any of the "LDAP_OPT_X_SASL_" options appears to require an initialized LDAP struct, as noted in the bug report against python-ldap, whereas most other options do not appear to share this requirement. I cannot find this fact documented anywhere. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9841] New: Build failure on musl due to conflicting declarations of ber_calloc
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9841 Issue ID: 9841 Summary: Build failure on musl due to conflicting declarations of ber_calloc Product: OpenLDAP Version: 2.5.11 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: helmut(a)subdivi.de Target Milestone: --- This is a forward of a Debian bug at https://bugs.debian.org/1008951 and a Gentoo bug at https://bugs.gentoo.org/546556. In essence, openldap #defines calloc ber_calloc and then #includes some system headers, which happen to #include <sched.h>. musl's <sched.h> happens to delcare calloc when _GNU_SOURCE is #defined. Since this is the case, musl's declaration is diverted to ber_calloc and since one parameter has a subtly different type, the declarations cause a conflict. I think this is actually two bugs. 1. musl should not declare calloc in <sched.h>. Doing so also breaks libgccjit (citation needed). 2. openldap should not #define calloc before #including system headers. Fixing either fixes the build failure. I think we should fix both. The openldap side can be fixed by reordering the #define and the relevant #include. You can find a working patch in the Debian bug above at https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1008951;filename=mu…. Does this look acceptable for inclusion into openldap? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9882] New: slapd crashes when lastbind enabled w/ multi-provider
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9882 Issue ID: 9882 Summary: slapd crashes when lastbind enabled w/ multi-provider 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: smckinney(a)symas.com Target Milestone: --- Created attachment 907 --> https://bugs.openldap.org/attachment.cgi?id=907&action=edit slapd.conf Description: Crash during bind operation when lastbind's enabled in a multi-provider env. Built from source: commit 23ef018c6f321413141f26ed6e1909f85047ba76 (HEAD -> OPENLDAP_REL_ENG_2_6, origin/OPENLDAP_REL_ENG_2_6) Configuration: attached System: AlmaLinux8 Backtrace: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000000004dfe66 in over_op_func (op=0x7d6b1fffe690, rs=0x7d6b1fffe620, which=op_modify) at backover.c:749 749 on = oi->oi_list; [Current thread is 1 (Thread 0x7d6b1ffff700 (LWP 96272))] Missing separate debuginfos, use: yum debuginfo-install cyrus-sasl-lib-2.1.27-6.el8_5.x86_64 glibc-2.28-189.5.el8_6.x86_64 keyutils-libs-1.5.10-9.el8.x86_64 krb5-libs-1.18.2-14.el8.x86_64 libblkid-2.32.1-35.el8.x86_64 libcap-2.48-2.el8.x86_64 libcom_err-1.45.6-4.el8.x86_64 libdb-5.3.28-42.el8_4.x86_64 libgcc-8.5.0-10.1.el8_6.alma.x86_64 libmount-2.32.1-35.el8.x86_64 libselinux-2.9-5.el8.x86_64 libtool-ltdl-2.4.6-25.el8.x86_64 libuuid-2.32.1-35.el8.x86_64 libxcrypt-4.1.1-6.el8.x86_64 openssl-libs-1.1.1k-6.el8_5.x86_64 pcre2-10.32-2.el8.x86_64 systemd-libs-239-58.el8.x86_64 zlib-1.2.11-18.el8_5.x86_64 (gdb) bt #0 0x00000000004dfe66 in over_op_func (op=0x7d6b1fffe690, rs=0x7d6b1fffe620, which=op_modify) at backover.c:749 #1 0x00000000004e0135 in over_op_modify (op=0x7d6b1fffe690, rs=0x7d6b1fffe620) at backover.c:808 #2 0x000000000046d785 in fe_op_lastbind (op=0x7d6b1010ed40) at bind.c:503 #3 0x000000000046da7f in fe_op_bind_success (op=0x7d6b1010ed40, rs=0x7d6b1fffe960) at bind.c:548 #4 0x000000000046d1e1 in fe_op_bind (op=0x7d6b1010ed40, rs=0x7d6b1fffe960) at bind.c:386 #5 0x000000000046c8cd in do_bind (op=0x7d6b1010ed40, rs=0x7d6b1fffe960) at bind.c:206 #6 0x000000000044427d in connection_operation (ctx=0x7d6b1fffea90, arg_v=0x7d6b1010ed40) at connection.c:1115 #7 0x000000000044488f in connection_read_thread (ctx=0x7d6b1fffea90, argv=0x16) at connection.c:1267 #8 0x00007f5f2d60a470 in ldap_int_thread_pool_wrapper (xpool=0xc79d80) at tpool.c:1053 #9 0x00007f5f2c1a51cf in start_thread () from /lib64/libpthread.so.0 #10 0x00007f5f2be11dd3 in clone () from /lib64/libc.so.6 -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9847] New: kqueue problem with OpenBSD
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9847 Issue ID: 9847 Summary: kqueue problem with OpenBSD Product: OpenLDAP Version: 2.6.2 Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stu(a)spacehopper.org Target Milestone: --- The kqueue support added to slapd for 2.5 isn't working correctly on OpenBSD. If slapd runs as a daemon, errors like these are seen: slap_client_connect: URI=ldaps://XXX Warning, ldap_start_tls failed (1) mdb_opinfo_get: err Invalid argument(22) However if slapd is run in the foreground with -d, things are ok. They are also OK if kqueue is disabled (by neutering the autoconf check). I've tested 2.5.4, 2.5.9 and 2.6.2. Here are some log excerpts: 17:23:44.692: slapd starting 17:23:44.692: daemon: added 3r listener=0x0 17:23:44.692: daemon: added 6r listener=0x100263797200 17:23:44.692: daemon: added 7r listener=0x100263785400 17:23:44.692: daemon: kqueue: listen=6 active_threads=0 tvp=zero 17:23:44.692: daemon: kqueue: listen=7 active_threads=0 tvp=zero 17:23:44.692: daemon: activity on 1 descriptor 17:23:44.692: daemon: activity on: 17:23:44.692: 17:23:44.692: daemon: kqueue: listen=6 active_threads=0 tvp=zero 17:23:44.692: daemon: kqueue: listen=7 active_threads=0 tvp=zero 17:23:44.692: >>> dnNormalize: <cn=Consumer 101> 17:23:44.692: <<< dnNormalize: <cn=consumer 101> 17:23:44.692: =>do_syncrepl rid=101 17:23:44.763: slap_client_connect: URI=ldaps://XXXXXXXXXXXXXXX Warning, ldap_start_tls failed (1) 17:23:44.781: => mdb_entry_get: ndn: "dc=XXXXXXX,dc=XXX" 17:23:44.782: => mdb_entry_get: oc: "(null)", at: "contextCSN" 17:23:44.782: mdb_opinfo_get: err Invalid argument(22) 17:23:44.782: =>do_syncrep2 rid=101 17:23:44.782: daemon: added 9r listener=0x0 17:23:44.783: daemon: activity on 1 descriptor 17:23:44.783: daemon: activity on: 17:23:44.783: 17:23:44.783: daemon: kqueue: listen=6 active_threads=0 tvp=NULL 17:23:44.783: daemon: kqueue: listen=7 active_threads=0 tvp=NULL 17:23:44.800: daemon: activity on 1 descriptor 17:23:44.800: daemon: activity on: 17:23:44.800: 9r 17:23:44.800: 17:23:44.800: daemon: read active on 9 17:23:44.800: daemon: kqueue: listen=6 active_threads=0 tvp=NULL 17:23:44.800: daemon: kqueue: listen=7 active_threads=0 tvp=NULL 17:23:44.800: connection_get(9) 17:23:44.800: connection_get(9): got connid=0 17:23:44.801: =>do_syncrepl rid=101 17:23:44.801: =>do_syncrep2 rid=101 Not sure if it's any help but looking at kdump(1) output after a run under ktrace(1) I didn't spot the immediate problem resulting in "ldap_start_tls failed (1)" however the "mdb_opinfo_get: err Invalid argument(22)" occurs after attempting to call fcntl with F_SETLK on the fd 5 which is the kqueue fd: 65304 slapd RET write 97/0x61 65304 slapd CALL poll(0x89d39cb9004,1,INFTIM) 65304 slapd STRU struct kevent [2] { ident=9, filter=EVFILT_READ, flags=0x1005<EV_ADD|EV_ENABLE>, fflags=0<>, data=0, udata=0x231a1bea } { ident=9, filter=EVFILT_EXCEPT, flags=0x1005<EV_ADD|EV_ENABLE>, fflags=0x4<>, data=0, udata=0x231a1bea } 65304 slapd STRU struct kevent { ident=9, filter=EVFILT_READ, flags=0x1005<EV_ADD|EV_ENABLE>, fflags=0<>, data=36, udata=0x231a1bea } 65304 slapd STRU struct pollfd { fd=9, events=0x3<POLLIN|POLLPRI>, revents=0x1<POLLIN> } 65304 slapd RET poll 1 65304 slapd CALL read(9,0x89ccfb103e0,0x5) 65304 slapd GIO fd 9 read 5 bytes "\^W\^C\^C\0\^_" 65304 slapd RET read 5 65304 slapd CALL read(9,0x89ccfb349c5,0x1f) 65304 slapd GIO fd 9 read 31 bytes "\M^W\M-r\M-f\M^C\M-2\M^V\M-E\^O\M-hdgq\M-"\M-o\M-&\M^[*\M-9\M^E\M-Sd\M^A2\M-QE\M-cb |\M^VI" 65304 slapd RET read 31/0x1f 65304 slapd CALL mmap(0,0x2000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) 65304 slapd RET mmap 9468564512768/0x89c926ca000 65304 slapd CALL fcntl(5,F_SETLK,0x8ef465d0) 65304 slapd RET fcntl -1 errno 22 Invalid argument 65304 slapd CALL getpid() 65304 slapd RET getpid 65304/0xff18 65304 slapd CALL sendsyslog(0x89c8ef44040,59,0<>) 65304 slapd GIO fd -1 wrote 59 bytes "<167>slapd[65304]: mdb_opinfo_get: err Invalid argument(22)" Any suggestions or requests for further information/tests would be welcome. Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

1 16

[Issue 9868] New: backglue and syncprov must use same pending_csn_list
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9868 Issue ID: 9868 Summary: backglue and syncprov must use same pending_csn_list Product: OpenLDAP Version: 2.5.12 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: --- When replication is performed on a glued DB hierarchy the syncprov overlay must only be configured on the top DB. But when writes occur on a subDB their CSNs will be queued on the subDB's be_pending_csn_list. When syncprov sees these writes it will try to graduate these CSNs from the top DB's be_pending_csn_list, but never find them there. The CSN list will grow without bound. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

14 Jul '22

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

1 30

[Issue 9883] New: OpenLDAP version 2.4.44 for CentoOS 7.9 contains several CVEs
by openldap-its＠openldap.org 12 Jul '22

12 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9883 Issue ID: 9883 Summary: OpenLDAP version 2.4.44 for CentoOS 7.9 contains several CVEs Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: meirav.rath(a)imperva.com Target Milestone: --- Hello, My name is Meirav Rath, I'm a software developer and security champion at Imperva. As part of our effort to map security risks in our products I've been scanning our 3rd party rpms for vulnerabilities. It looks like OpenLDAP version 2.4.44 for CentOS 7.9 has the following security issues: 1. CVE-2020-36229 - https://nvd.nist.gov/vuln/detail/CVE-2020-36229 2. CVE-2019-13565 - https://nvd.nist.gov/vuln/detail/CVE-2019-13565 3. CVE-2020-36223 - https://nvd.nist.gov/vuln/detail/CVE-2020-36223 4. CVE-2020-36222 - https://nvd.nist.gov/vuln/detail/CVE-2020-36222 5. CVE-2019-13057 - https://nvd.nist.gov/vuln/detail/CVE-2019-13057 6. CVE-2021-27212 - https://nvd.nist.gov/vuln/detail/CVE-2021-27212 7. CVE-2020-36226 - https://nvd.nist.gov/vuln/detail/CVE-2020-36226 8. CVE-2020-36228 - https://nvd.nist.gov/vuln/detail/CVE-2020-36228 9. CVE-2022-29155 - https://nvd.nist.gov/vuln/detail/CVE-2022-29155 10. CVE-2020-36230 - https://nvd.nist.gov/vuln/detail/CVE-2020-36230 11. CVE-2020-36225 - https://nvd.nist.gov/vuln/detail/CVE-2020-36225 12. CVE-2020-36227 - https://nvd.nist.gov/vuln/detail/CVE-2020-36227 13. CVE-2020-36224 - https://nvd.nist.gov/vuln/detail/CVE-2020-36224 14. CVE-2020-36221 - https://nvd.nist.gov/vuln/detail/CVE-2020-36221 When can we expect an updated RPM with fixes for this issues, aimed for CentOS7.9? Thanks. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9782] New: regression test its8752 failure
by openldap-its＠openldap.org 08 Jul '22

08 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9782 Issue ID: 9782 Summary: regression test its8752 failure Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If a contextCSN update (new cookie) goes from server A through server B to server C, server C will use that CSN to update entryCSN as well (which neither A nor B did). This fails the initial replication check. The issue has likely existed since deltasync was made possible, a version of this is confirmed at least in 2.4.60 onwards to current master. In principle, it is related to concerns raised in ITS#9580. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8752] MMR delta-sync deadlock using slapd.conf
by openldap-its＠openldap.org 08 Jul '22

08 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=8752 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9782 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9879] New: Crash in bindconf_free
by openldap-its＠openldap.org 07 Jul '22

07 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9879 Issue ID: 9879 Summary: Crash in bindconf_free 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: dpa-openldap(a)aegee.org Target Milestone: --- Slapd 2.6 (git commit 0dc9ff2594da) produes at start this output: free(): invalid pointer . The core-dump is: gdb /git/openldap bt f #0 __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:45 pid = 3060261 tid = 3060261 pd = <optimized out> val = 0 tid = <optimized out> pd = <optimized out> val = <optimized out> sc_ret = <optimized out> resultvar = <optimized out> __x = <optimized out> pid = <optimized out> resultvar = <optimized out> __arg3 = <optimized out> __arg2 = <optimized out> __arg1 = <optimized out> _a3 = <optimized out> _a2 = <optimized out> _a1 = <optimized out> #1 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at pthread_kill.c:62 No locals. #2 0x00007ff2445a91f2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 ret = <optimized out> #3 0x00007ff24459443b in __GI_abort () at abort.c:79 save_stage = 1 act = { __sigaction_handler = { sa_handler = 0x7ff244e0b590, sa_sigaction = 0x7ff244e0b590 }, sa_mask = { __val = {140678513857256, 140678514176000, 0, 4360521566522441729, 4294967295, 17981341232831397889, 140678513857472, 140678514176000, 140678513858576, 140678514161728, 37835024, 140678514167232, 5433280, 140727718055568, 140727718055515, 140678514247725} }, sa_flags = 1, sa_restorer = 0x0 } sigs = { __val = {32, 1, 140678501620784, 1, 0, 1, 140678514176000, 1, 140678501620784, 140678514176000, 140678514176880, 0, 140678514389536, 1, 140677358813185, 4294967295} } #4 0x00007ff2445e7c00 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ff2447185f4 "%s\n") at ../sysdeps/posix/libc_fatal.c:155 ap = {{ gp_offset = 24, fp_offset = 0, overflow_arg_area = 0x7ffdb9a4f2e0, reg_save_area = 0x7ffdb9a4f270 }} [31/1957] fd = <optimized out> list = <optimized out> nlist = <optimized out> cp = <optimized out> #5 0x00007ff2445fc64a in malloc_printerr (str=str@entry=0x7ff244716247 "free(): invalid pointer") at malloc.c:5543 No locals. #6 0x00007ff2445fddbc in _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:4326 size = 0 fb = <optimized out> nextchunk = <optimized out> nextsize = <optimized out> nextinuse = <optimized out> prevsize = <optimized out> bck = <optimized out> fwd = <optimized out> __PRETTY_FUNCTION__ = "_int_free" #7 0x00007ff244600821 in __GI___libc_free (mem=<optimized out>) at malloc.c:3278 ar_ptr = <optimized out> p = <optimized out> err = 13 #8 0x000000000041ab72 in bindconf_free (bc=bc@entry=0x52b970 <ldifocs+48>) at config.c:1611 No locals. #9 0x000000000046b908 in syncinfo_free (sie=0x52b940 <ldifocs>, free_all=free_all@entry=1) at syncrepl.c:6052 si_next = 0x4d8530 #10 0x0000000000429815 in backend_destroy_one (bd=0x52d8f0 <cfBackInfo+16>, dynamic=0) at backend.c:456 No locals. #11 0x000000000041651a in config_back_db_destroy (be=<optimized out>, cr=<optimized out>) at bconfig.c:7610 cfb = 0x52d8e0 <cfBackInfo> #12 0x000000000042981d in backend_destroy_one (bd=0x2445920, dynamic=1) at backend.c:459 No locals. #13 0x000000000042993a in backend_destroy () at backend.c:498 bd = <optimized out> bi = <optimized out> #14 0x000000000043e04f in slap_destroy () at init.c:258 rc = <optimized out> #15 0x000000000040a12c in main (argc=<optimized out>, argv=0x7ffdb9a4f628) at main.c:890 i = <optimized out> no_detach = <optimized out> rc = 1 urls = 0x7ffdb9a50e90 "ldap://ldap.aegee.org/ ldaps://ldap.aegee.org ldapi://%2Fvar%2Frun%2Fldapi" username = 0x7ffdb9a50e60 "openldap" groupname = 0x0 sandbox = 0x7ffdb9a50e6c "/home/openldap" pid = <optimized out> waitfds = {38815280, 0} g_argc = <optimized out> g_argv = 0x7ffdb9a4f628 configfile = 0x0 configdir = 0x7ffdb9a50e7e "/etc/openldap/" serverMode = 1 scp = <optimized out> scp_entry = <optimized out> serverNamePrefix = <synthetic pointer> l = <optimized out> slapd_pid_file_unlink = <optimized out> slapd_args_file_unlink = <optimized out> firstopt = <optimized out> Going back to commit 2cf617938 does work fine. To be precise, openldap reads certificates from its chrooted file - chr/etc/openssl/certs/ca-bundle.crt , but it had no read-access to the chr/etc/openssl/certs directory. At commit 2cf617938 does not crash at the latest 2.6 it crashes. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9534] New: Persistent test043 failures
by openldap-its＠openldap.org 07 Jul '22

07 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9534 Issue ID: 9534 Summary: Persistent test043 failures Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- In testing current RE25 as of 4/23/2021 (73b2769d05529a7d474661023f2c4f3a931417b2) test043 is sporadically failing. Examining the testrun log, it appears replication never even initiated. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9877] New: Session Tracking failing to log IP addresses
by openldap-its＠openldap.org 05 Jul '22

05 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9877 Issue ID: 9877 Summary: Session Tracking failing to log IP addresses Product: OpenLDAP Version: unspecified 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: --- From slapd log in master with session tracking enabled: 62c45cfe.3b59f358 0x7fa3b0aa8700 conn=1002 fd=15 ACCEPT from IP=127.0.0.1:58790 (IP=127.0.0.1:9012) 62c45cff.017af6f5 0x7fa3b0aa8700 conn=1002 op=1 [IP=[ USERNAME=cn=manager,dc=example,dc=com] modifications: 62c45cff.017b2c53 0x7fa3b0aa8700 conn=1002 op=1 [IP=[ USERNAME=cn=manager,dc=example,dc=com] MOD dn="cn=replicator,dc=example,dc=com" 62c45cff.017bb35e 0x7fa3b0aa8700 conn=1002 op=1 [IP=[ USERNAME=cn=manager,dc=example,dc=com] MOD attr=pwdLastSuccess Note the missing IP address. This works correctly in current 2.6.2 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9874] New: slapadd is returning garbage error data
by openldap-its＠openldap.org 05 Jul '22

05 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9874 Issue ID: 9874 Summary: slapadd is returning garbage error data 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 slapadd encounters an error, instead of returning that error it is returning garbage text. Example: slapadd: could not add entry dn="olcDatabase={1}mdb,cn=config" (line=1119): #]I Note the: "#]I" If run with -d -1, we see the actual error is: mdb_db_init: Initializing mdb database olcDbDirectory: value #0: invalid path: No such file or directory slapadd: could not add entry dn="olcDatabase={1}mdb,cn=config" (line=1119): olcDbDirectory: value #0: invalid path: No such file or directory slapadd shutdown: initiated -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9642] New: Adding a task to runqueue doesn't wake the main thread
by openldap-its＠openldap.org 05 Jul '22

05 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9642 Issue ID: 9642 Summary: Adding a task to runqueue doesn't wake the main thread Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If a connection adds a new syncrepl stanza, that is not started until the main thread comes around to doing it. However if that thread is currently stuck in SLAP_EVENT_WAIT() and nothing else happens (like an unbind over the connection that modified the config), the task is never started. This can take a long time. No idea yet how to wake it up with/from ldap_pvt_runqueue_insert() given that sits within libldap and not really something that should be calling slap_wake_listener(). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9875] New: OpenLDAP 2.6 libldap_r.so is missing
by openldap-its＠openldap.org 05 Jul '22

05 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9875 Issue ID: 9875 Summary: OpenLDAP 2.6 libldap_r.so is missing Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: andysyam61(a)gmail.com Target Milestone: --- OpenLDAP 2.6 libldap_r.so is missing https://github.com/python-ldap/python-ldap/issues/432 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9468] New: slapd-ldap does anonymous bind even if rebind-as-user is set
by openldap-its＠openldap.org 30 Jun '22

30 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9468 Issue ID: 9468 Summary: slapd-ldap does anonymous bind even if rebind-as-user is set Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: tero.saarni(a)est.tech Target Milestone: --- When back-ldap retries bind operation after connection retry, it will do it as anonymous even if rebind-as-user is set to yes. Expected behavior is that (re)bind is done with user's credentials from the initial bind operation. I observed following (Warning: I might have understood details of the code incorrectly): When rebind-as-user is set and bind operation from client is processed, proxy will copy the credentials to ldapconn_t representing the remote LDAP connection. When remote LDAP connection is closed (e.g. by the proxy itself due to timeout), the bind credentials information is lost when freeing the old ldapconn_t. At this point, client still holds the connection to proxy and is unaware of the remote connection being lost. Proxy then re-establishes the connection and "synthetically" generates new bind itself, but since it does not have the credentials stored in memory anymore, it sends anonymous bind on behalf of the client. As a side effect, slapd currently crashes if remote server does not allow anonymous bind and responds with InvalidCredentials instead. The crash is due to assert(), which is handled in separate issue https://bugs.openldap.org/show_bug.cgi?id=9288 -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 6166] Overlay/backend restructuring
by openldap-its＠openldap.org 29 Jun '22

29 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=6166 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- See also https://git.openldap.org/openldap/openldap/-/merge_requests/543#note_4422 for thoughts on ppolicy as well. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7468] ppolicy and rwm/relay segfaulting
by openldap-its＠openldap.org 29 Jun '22

29 Jun '22

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

1 0

[Issue 7966] OpenLDAP server 2.4.40 crashes with rwm and ppolicy overlay during bind
by openldap-its＠openldap.org 24 Jun '22

24 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=7966 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 7966] OpenLDAP server 2.4.40 crashes with rwm and ppolicy overlay during bind
by openldap-its＠openldap.org 24 Jun '22

24 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=7966 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also|https://bugs.openldap.org/s | |how_bug.cgi?id=9871 | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7966] OpenLDAP server 2.4.40 crashes with rwm and ppolicy overlay during bind
by openldap-its＠openldap.org 24 Jun '22

24 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=7966 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|6166 | Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Target Milestone|2.7.0 |--- --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** This issue has been marked as a duplicate of issue 9871 *** Referenced Issues: https://bugs.openldap.org/show_bug.cgi?id=6166 [Issue 6166] Overlay/backend restructuring -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6166] Overlay/backend restructuring
by openldap-its＠openldap.org 24 Jun '22

24 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=6166 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|7966 | Referenced Issues: https://bugs.openldap.org/show_bug.cgi?id=7966 [Issue 7966] OpenLDAP server 2.4.40 crashes with rwm and ppolicy overlay during bind -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7966] OpenLDAP server 2.4.40 crashes with rwm and ppolicy overlay during bind
by openldap-its＠openldap.org 23 Jun '22

23 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=7966 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9871 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9862] New: segmentation fault in ldap_simple_bind_s and openssl
by openldap-its＠openldap.org 23 Jun '22

23 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9862 Issue ID: 9862 Summary: segmentation fault in ldap_simple_bind_s and openssl Product: OpenLDAP Version: 2.4.49 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: atsoi(a)marklogic.com Target Milestone: --- We have segmentation fault when using ldap_simple_bind_s. The openldap version is 2.4.59 The openssl version is 1.0.2zd. 2021-05-09 01:11:22.021 Critical:+#5 0x00007f8f7212a038 in signalHandler(int, siginfo_t, void) () from /usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.282.b08-1.el7_9.x86_64/lib/amd64/server/libjvm.so 2021-05-09 01:11:22.021 Critical:+#6 2021-05-09 01:11:22.021 Critical:+#7 0x00007f8f78dc7f6e in BIO_set () from lib/libcrypto.so.1.0.0 2021-05-09 01:11:22.021 Critical:+#8 0x00007f8f78dc7fe2 in BIO_new () from lib/libcrypto.so.1.0.0 2021-05-09 01:11:22.021 Critical:+#9 0x00007f8f78a34574 in tlso_sb_setup () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#10 0x00007f8f787f6062 in ber_sockbuf_add_io () from lib/liblber-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#11 0x00007f8f78a31a68 in ldap_int_tls_connect.isra.1 () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#12 0x00007f8f78a32288 in ldap_int_tls_start () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#13 0x00007f8f78a0da70 in ldap_int_open_connection () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#14 0x00007f8f78a2014d in ldap_new_connection () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#15 0x00007f8f78a0d15a in ldap_open_defconn () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#16 0x00007f8f78a21568 in ldap_send_initial_request () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#17 0x00007f8f78a167a2 in ldap_sasl_bind () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#18 0x00007f8f78a16b8a in ldap_sasl_bind_s () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#19 0x00007f8f78a172e0 in ldap_simple_bind_s () from lib/libldap_r-2.4.so.2 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8245] slapo-unique constraints bypassed by manageDsaIt, change to relax?
by openldap-its＠openldap.org 23 Jun '22

23 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=8245 --- Comment #15 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 81b5ca91 by Ondřej Kuzník at 2022-06-14T21:52:18+00:00 ITS#8245 Do not try to release a NULL entry RE26 (2.6.3): • 85649edf by Ondřej Kuzník at 2022-06-23T18:34:57+00:00 ITS#8245 Do not try to release a NULL entry RE25 (2.5.13): • c8059b5d by Ondřej Kuzník at 2022-06-23T18:46:44+00:00 ITS#8245 Do not try to release a NULL entry -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8227] syncprov should use more threads
by openldap-its＠openldap.org 23 Jun '22

23 Jun '22

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

1 0

[Issue 9870] New: Remove optional overlay syntax
by openldap-its＠openldap.org 23 Jun '22

23 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9870 Issue ID: 9870 Summary: Remove optional overlay syntax 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: --- While the module/overlay support was really young, an unreleased version of OpenLDAP supported 'optional overlays' that could fail start up without that being treated as a fatal error. This was later disabled, never documented and nowadays it can't work anyway, but the configuration option is still there in config_overlay() honouring overlay names starting with the '-' character as an alias. A patch to remove that leftover is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9869] New: LDAP over TLS not doing hostname verification in version 2.4.59
by openldap-its＠openldap.org 21 Jun '22

21 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9869 Issue ID: 9869 Summary: LDAP over TLS not doing hostname verification in version 2.4.59 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: radiatejava(a)gmail.com Target Milestone: --- My software was using openldap client 2.4.44 to talk to the LDAP server. We have shifted to 2.4.59 now to address some issues. Ever since we shifted, the new version is allowing LDAP over TLS without hostname verification. In the older 2.4.44, I always got this error if hostname did not match the CN value: return code -1 - Can't contact LDAP server) diagnostic message TLS: hostname does not match CN in peer certificate But after the lib update, no such error even if I am using LDAP server IP to do LDAP bind while LDAP server certificate has CN set as some FQDN (say test.ldap.com). Our client side code has not changed while we updated the ldap lib. For our client, we are only doing these settings: ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTDIR, lCertsDir) ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, lCert) Has there been any change in this regard? How do I enforce hostname verification now? Thanks -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 8227] syncprov should use more threads
by openldap-its＠openldap.org 21 Jun '22

21 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=8227 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Yeah, just gone all the way to backlogging one consumer till we block in slapd_wait_writer() and the other one keeps receiving all messages as they are prepared, just as one would hope. Resuming the blocked consumer seems to flush everything down that connection as well. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8227] syncprov should use more threads
by openldap-its＠openldap.org 21 Jun '22

21 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=8227 --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- Possibly this ticket is obsolete then. If you're satisfied that suspending/blocking one consumer doesn't interfere with other consumers' progress, we can just close this. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8227] syncprov should use more threads
by openldap-its＠openldap.org 21 Jun '22

21 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=8227 --- Comment #4 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Maybe you meant something else because I'm not seeing this, syncprov_matchops->syncprov_qresp already schedules a separate syncprov_qtask for each active persist session that has anything to send out. Those sessions each have a separate response queue, sharing a reference to the resinfo provided. And those tasks then run independent of each other sending messages (since ITS#5985 just one message at a time), reclaiming syncres and since ITS#8039 possibly resinfo as they make progress. Also verified all of this at runtime. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6942] updateref config is inadequate
by openldap-its＠openldap.org 13 Jun '22

13 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=6942 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|--- |High --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Fairly critical for 2.7.0 so that we can better handle replicated environments with chaining where MMR is in play. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9861] New: Read-only databases can't be opened - regression introduced with da0527ac
by openldap-its＠openldap.org 09 Jun '22

09 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9861 Issue ID: 9861 Summary: Read-only databases can't be opened - regression introduced with da0527ac Product: LMDB Version: unspecified Hardware: aarch64 OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: jocke(a)ordo.one Target Milestone: --- Created attachment 905 --> https://bugs.openldap.org/attachment.cgi?id=905&action=edit Reduced simple test to open the environment that fails The ability to open an environment in read-only mode when the file permissions is 'read only' for the user is no longer possible after the commit da0527ac75b811419b7007202799f96b2edb5aef. It is simply reproduced by creating a database with e.g. mtest.c, then changing the permissions to read-only, then running another trivial program trying to open the environment in read-only mode / no-lock mode fails. Specifically, after some investigation it seems that the check on line 5516 "if (!(flags & (MDB_RDONLY|MDB_WRITEMAP))) {" was removed in the above commit such that mdb_fopen() is called (presumably incorrectly?). Returning that guard check seems to restore functionality, but I'm not familiar enough with the code base to say that is a valid fix - but seems likely. I applied that single change here: https://github.com/hassila/swift-lmdb/tree/hassila-mdb-merge-patch with this commit: https://github.com/hassila/swift-lmdb/commit/c940b4c807c278cea43d2e3858dc22… To reproduce with a clean checkout: 1. make 2. mkdir tested 3. ./mtest 4. chmod -wx testdb/data.mdb 5. run the attached program (reduced from real code base) -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9859] New: fix test
by openldap-its＠openldap.org 09 Jun '22

09 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9859 Issue ID: 9859 Summary: fix test Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- Created attachment 904 --> https://bugs.openldap.org/attachment.cgi?id=904&action=edit openldap-2.5-fix_test.patch 1. specifiy modulepath and moduleload moduleload ../rel/mod.la works on build directry ex: make test but it doesn't work with installed slapd. It should be specified the modulepath and moduleload separately like other tests. ``` modulepath ../servers/slapd/overlays/ moduleload mod.la ``` 2. skip test020-proxycache for back-wt -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9799] New: Clearing pending ops on Bind
by openldap-its＠openldap.org 07 Jun '22

07 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9799 Issue ID: 9799 Summary: Clearing pending ops on Bind 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: --- When slapd receives some operations before it has started processing a queued bind, those get added into conn->c_ops_pending and c_n_pending_ops is updated accordingly. Bind then eventually invokes connection_abandon() which forgets to zero out c_n_pending_ops and the connection remains unusable forever. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 6461] back-sql quote characters in query
by openldap-its＠openldap.org 07 Jun '22

07 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=6461 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.0 |2.5.12 Group|OpenLDAP-devs | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9157] return additional error code information when OPT_X_TLS_NEWCTX fails
by openldap-its＠openldap.org 03 Jun '22

03 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9157 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 2c0707cf by Howard Chu ITS#9157: check for NULL ld RE26 (2.6.3): • 6675535c by Howard Chu at 2022-06-03T20:29:24+00:00 ITS#9157: check for NULL ld -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9020] Inconsistent cn=config objectClasses for overlays
by openldap-its＠openldap.org 03 Jun '22

03 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9020 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 737bcd7f by Ondřej Kuzník at 2022-06-03T16:52:37+00:00 ITS#9020 Reinstate olcAutomaticGroups and document its deprecation RE26 (2.6.3): • 4a755258 by Ondřej Kuzník at 2022-06-03T17:42:35+00:00 ITS#9020 Reinstate olcAutomaticGroups and document its deprecation RE25 (2.5.13): • 02ddd515 by Ondřej Kuzník at 2022-06-03T17:43:55+00:00 ITS#9020 Reinstate olcAutomaticGroups and document its deprecation -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9857] New: add password policy
by openldap-its＠openldap.org 31 May '22

31 May '22

https://bugs.openldap.org/show_bug.cgi?id=9857 Issue ID: 9857 Summary: add password policy Product: OpenLDAP Version: 2.6.2 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: elizabeth.real(a)jpl.nasa.gov Target Milestone: --- I'm upgrading from openldap 2.4 running on RHEL7 up to 2.6.2 and RHEL8 on new hardware, apparently the way to configure password policy now is by configuring the slapd.conf file rather than loading the ppolicy schema. How do I modify that file properly? I read https://www.openldap.org/doc/admin26/overlays.html#Password%20Policies on section 12.10.2. Password Policy Configuration, what does it mean to "Instantiate the module in the database"? -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9854] New: We are best digital marketing
by openldap-its＠openldap.org 26 May '22

26 May '22

https://bugs.openldap.org/show_bug.cgi?id=9854 Issue ID: 9854 Summary: We are best digital marketing Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: moldshilarious50(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs