openldap-bugs

openldap-bugs@openldap.org

1 participants
21487 discussions

[Issue 10545] New: urltest leaks the parsed LDAPURLDesc and reconstructed URL string
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10545 Issue ID: 10545 Summary: urltest leaks the parsed LDAPURLDesc and reconstructed URL string Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 1489378385(a)qq.com Target Milestone: --- URL: https://github.com/openldap/openldap/blob/8afcbe9e04f1a40f03cea51c57418b05f… Description: Source revision: 8afcbe9e04f1a40f03cea51c57418b05f86e8f44 Affected file: libraries/libldap/urltest.c Affected lines: 75 and 125-127 Source-level observation: On a successful call, ldap_url_parse() allocates an LDAPURLDesc and stores it in lud. The program reaches its final return without calling ldap_free_urldesc(lud). There is also a second allocation on line 125: fprintf(stdout, "URL: %s\n", ldap_url_desc2str(lud)); ldap_url_desc2str() allocates its returned string with LDAP_MALLOC. Because the return value is passed directly to fprintf(), its pointer is lost and the string cannot be released. Steps to verify: 1. Build libraries/libldap/urltest with AddressSanitizer or LeakSanitizer. 2. Run it with a valid URL, for example: ./urltest 'ldap://localhost/dc=example,dc=com??sub?(objectClass=*)' 3. Allow the program to exit successfully. 4. Inspect the sanitizer report. Actual result: A successful invocation exits without releasing either the LDAPURLDesc or the string returned by ldap_url_desc2str(). Expected result: Both allocations should be released before returning from main(). Impact: Each successful run leaves two process-lifetime allocations. The practical impact is low because urltest is a short-lived test utility, but the ownership contracts are not followed and leak detectors report the allocations. Validation status: Confirmed by source review at the revision above. Runtime sanitizer validation is pending. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[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 8196] PRNG from ITS#7027 (shuffling DNS SRV records) is poorly seeded
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

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

1 0

[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 7981] Feature request: Crypt scheme in pwdPolicy
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

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

1 0

[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

[Issue 10085] New: test029 can't pass with SLAPD_USE_SASL is set
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10085 Issue ID: 10085 Summary: test029 can't pass with SLAPD_USE_SASL is set Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Running make test with SLAPD_USE_SASL set will fail test029. There is even a comment there that we can't support that functionality as-is when SASL binds are configured. We should probably remove that part of the test or skip it unconditionally for now. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9667] New: 2.6 to 2.7 upgrade documentation
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9667 Issue ID: 9667 Summary: 2.6 to 2.7 upgrade documentation 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: --- Need to document any upgrade information for going from 2.6 to 2.7 -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10265] New: Make it possible to change olcBkLloadListen at runtime
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10265 Issue ID: 10265 Summary: Make it possible to change olcBkLloadListen at runtime 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: --- Currently, olcBkLloadListen changes only take effect on lloadd startup: - an added olcBkLloadListen should come online at the end of the modify operation - at the end of the modify operation a removed olcBkLloadListen will stop listening on the sockets associated with it, clients that connected over these are marked CLOSING - to facilitate replacing a value where URIs resolved sockets overlap, olcBkLloadListen should become a MAY in olcBkLloadConfig objectclass Lloadd's startup was modelled upon slapd's, but the requirements have changed considerably when it was turned into a module. Sockets are acquired at module configuration time, which is much later than standalone/slapd's own startup and so the way the URLs are handled also needs to be reworked. This will resolve other related issues. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

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