openldap-bugs August 2024

openldap-bugs@openldap.org

1 participants
161 discussions

[Issue 10202] New: slapd fails to start if compiled with --enable-overlays=yes
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10202 Issue ID: 10202 Summary: slapd fails to start if compiled with --enable-overlays=yes Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Statically compiling all overlays produces the following error at slapd startup: 66192034.2adbbeb4 0x73de9d4547c0 register_at: AttributeType "( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that the entry belongs to' SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' EQUALITY distinguishedNameMatch USAGE dSAOperation NO-USER-MODIFICATION X-ORIGIN 'iPlanet Delegated Administrator' )": Duplicate attributeType, 1.2.840.113556.1.2.102 66192034.2adc2a97 0x73de9d4547c0 overlay_register("nestgroup"): name already in use. 66192034.2adc44ed 0x73de9d4547c0 nestgroup overlay setup failed, err -1 66192034.2adc5016 0x73de9d4547c0 slapd: overlay_init failed 66192034.2adc5e14 0x73de9d4547c0 slapd destroy: freeing system resources. 66192034.2adefbff 0x73de9d4547c0 slapd stopped. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10151] New: Leaks in do_syncrep2() when error handling
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10151 Issue ID: 10151 Summary: Leaks in do_syncrep2() when error handling 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: --- Investigating the persistent CI failures in test050, I can see some memory leaks that should be tackled (if only to reduce noise). For one, when receiving an entry without a syncrepl control attached or when dealing with a concurrent thread removing that consumer, we leak our scratch data (decoded controls, modlist, ...). -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9870] New: Remove optional overlay syntax
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

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 3

[Issue 10053] New: liblber/idtest.c (and psap.h dependency) irrelevant to OpenLDAP
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10053 Issue ID: 10053 Summary: liblber/idtest.c (and psap.h dependency) irrelevant to OpenLDAP Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- configure.ac checks for psap.h presence, the only user being liblber's idtest.c - a test program that uses none of liblber API and claims to be part of ISODE X.500 code. I'm tempted to remove the configure check and the source file, letting that project adopt it if they still use it for something. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9497] New: back-ldif: test022-ppolicy failure
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9497 Issue ID: 9497 Summary: back-ldif: test022-ppolicy failure Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- The test022-ppolicy with back-ldif fail for two issue. 1. too short pwdMaxAge ~~~ $ ./run -b ldif test022-ppolicy (snip) Testing password expiration Waiting seconds for password to expire... sleep: missing operand Try 'sleep --help' for more information. Password expiration test failed ~~~ The script tries test for lockout and then a test for password expiration. It will fail if the password has expired(pwdMaxAge: 30) by the time it starts the password expiration test. This is a timing issue and not directly caused by back-ldif. However, the issue is reproduced only with back-ldif in my environment. This test passed in my environment by extending pwdMaxAge by 5 seconds, but there may be a better way. 2. duplicate ldap control response ~~~ Reconfiguring policy to remove grace logins... Clearing forced reset... expr: syntax error: unexpected argument '15' Testing password expiration Waiting seconds for password to expire... sleep: missing operand Try 'sleep --help' for more information. ~~~ This is back-ldif issue. back-ldif responds duplicate ldap control response. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9739] New: Undefined reference to ber_sockbuf_io_udp in 2.6.0
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9739 Issue ID: 9739 Summary: Undefined reference to ber_sockbuf_io_udp in 2.6.0 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: simon.pichugin(a)gmail.com Target Milestone: --- While I was trying to build OpenLDAP 2.6 on Fedora Rawhide I've got the error message: /usr/bin/ld: ./.libs/libldap.so: undefined reference to `ber_sockbuf_io_udp' I've checked commits from https://bugs.openldap.org/show_bug.cgi?id=9673 and found that 'ber_sockbuf_io_udp' was not added to https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/… I've asked on the project's mailing list and got a reply: "That symbol only exists if OpenLDAP is built with LDAP_CONNECTIONLESS defined, which is not a supported feature. Feel free to file a bug report at https://bugs.openldap.org/" https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… Hence, creating the bug. -- You are receiving this mail because: You are on the CC list for the issue.

1 21

[Issue 9593] New: excessive null check in set_chase()
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9593 Issue ID: 9593 Summary: excessive null check in set_chase() Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Looks like slap_set_join( cp, nset, '|', vals ) can't return null, so return value at line 411 should be treated like one at line 402: servers/slapd/sets.c:399, set_chase(): for ( i = 0; !BER_BVISNULL( &set[ i ] ); i++ ) { vals = gatherer( cp, &set[ i ], desc ); if ( vals != NULL ) { /*402: */ nset = slap_set_join( cp, nset, '|', vals ); } } ber_bvarray_free_x( set, cp->set_op->o_tmpmemctx ); if ( closure ) { for ( i = 0; !BER_BVISNULL( &nset[ i ] ); i++ ) { vals = gatherer( cp, &nset[ i ], desc ); if ( vals != NULL ) { /*411: */ nset = slap_set_join( cp, nset, '|', vals ); if ( nset == NULL ) { break; } } } } diff --git a/servers/slapd/sets.c b/servers/slapd/sets.c index fc7b72c8b..17a6ec2c1 100644 --- a/servers/slapd/sets.c +++ b/servers/slapd/sets.c @@ -409,9 +409,6 @@ set_chase( SLAP_SET_GATHER gatherer, vals = gatherer( cp, &nset[ i ], desc ); if ( vals != NULL ) { nset = slap_set_join( cp, nset, '|', vals ); - if ( nset == NULL ) { - break; - } If I'm wrong, return value at line 402 must be checked for null. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10060] New: libldap: ldap_result return value differs depending on if a search response is already in the response list or not
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10060 Issue ID: 10060 Summary: libldap: ldap_result return value differs depending on if a search response is already in the response list or not Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: david(a)hardeman.nu Target Milestone: --- ldap_result(3) is defined here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… On this line, ldap_result will call wait4msg: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… wait4msg is defined here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… If a response for a given msgid is already stored in the response list, and all=1, the whole message chain will be returned by the call from wait4msg to chkResponseList here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… And rc will be set on the next line to the head of the message chain. If a response for a given msgid is *not* already stored in the response list, wait4msg will eventually call try_read1msg here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… If try_read1msg manages to receive the final search result message for a given msgid, it will be noted here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… The whole chain will be returned here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… And the return code will be the tag of the *last* message in the chain, as opposed to the *first* message in the chain: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… Which will result in different return codes for chains of multiple messages (i.e. search results with all=1). -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 10254] New: Allow upgrading password hash on bind
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10254 Issue ID: 10254 Summary: Allow upgrading password hash on bind Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: me(a)floriswesterman.nl Target Milestone: --- Many OpenLDAP installations are likely to contain relatively old password hashes such as SSHA and CRYPT, as modern alternatives such as Argon are only recent additions. Due to the nature of password hashes, it is of course not possible to "unhash" the old values and rehash them with a more modern algorithm. The presence of these old password hashes poses a liability in case of information leaks or hacks. Currently, the only way to upgrade a password hash is to wait for the user to change their password. This can be sped up by expiring passwords and forcing users to change them. However, this can be slow and frequent password rotation is no longer considered a best practice. It would be a very helpful addition to add support for upgrading a password hash on bind. This is implemented in the 389 directory server: https://www.port389.org/docs/389ds/design/pwupgrade-on-bind.html Essentially, when a user binds, the password is checked like normal. In case of a successful bind, the proposed feature would check the hash algorithm used for the password; and in case it is not equal to the current `olcPasswordHash` value, the user-provided password is rehashed using the new algorithm and stored. This way, the old hashes are phased out more quickly, without being a disturbance to users. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9651] New: Add some kind of rate limiting option to ldapmodify
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9651 Issue ID: 9651 Summary: Add some kind of rate limiting option to ldapmodify Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When using ldapmodify to replay a testing workload it would be useful to be able to specify a request rate, instead of just performing multiple operations in immediate succession. As a simpler alternative, just being able to specify a time interval between operations would be helpful. As an even greater future enhancement, it would be nice to have an option to replay an accesslog.ldif directly, using its embedded timestamps to control the time interval between operations. Currently this isn't feasible since reqstart timestamps only have 1-second granularity, the fraction part is a linear counter and not a microsecond value. The reqStart fraction would need to be extended to 9 decimal places with full nanosecond resolution in order to be usable as actual fractional time. We already know that microsecond resolution is insufficient to avoid frequent collisions. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

← Newer
1
2
3
4
5
6
7
...
17
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2024