https://bugs.openldap.org/show_bug.cgi?id=6938
--- Comment #3 from Dhiraj Giria <dhiraj.giria(a)mitel.com> ---
Hi Matt
I have tried building OpenLDAP 2.6.9 version with flag enable-ipv6 flag for
Windows environment, but failed to do so successfully. Is it a valid ticket?
can you please confirm if we support openldap+ipv6 on Windows?
Thanks
Dhiraj
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10329
Issue ID: 10329
Summary: Additional issues with pcache, and a test
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: aweits(a)rit.edu
Target Milestone: ---
Created attachment 1062
--> https://bugs.openldap.org/attachment.cgi?id=1062&action=edit
test & patches
Hello again!
Further testing revealed some more issues in pcache [re: ITS#10270]. I've
attached an update to test020-proxycache as well. These are based off the
current git HEAD.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10328
Issue ID: 10328
Summary: Possible multiple free() calls in
rewrite_subst_compile()
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: gyf161023(a)gmail.com
Target Milestone: ---
In rewrite_subst_compile() of libraries/librewrite/subst.c line 216 and 222,
`subs` and `submatch` array are freed repeatedly on the index `nsub` instead of
l, is this what was intended or the `nsub` has some guarantee to be 1 so that
we are not freeing anything for second time?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10326
Issue ID: 10326
Summary: SNI passing requirements differ across TLS
implementations
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: ---
mbedtls 3.6.3 has changed behaviour to correct a long standing issue where not
setting a hostname meant hostname checking was disabled completely
(CVE-2025-27809).
It seems that how we do SNI vs. basic certificate checking differs between TLS
implementations and our logic in ldap_int_tls_connect and ti_session_connect.
This is also the reason test067-tls started failing on mbedtls builds.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10323
Issue ID: 10323
Summary: Starttls critical not working on lloadd
Product: OpenLDAP
Version: 2.6.9
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: grichier(a)scaleway.com
Target Milestone: ---
Hello,
Looks like starttls critical not working on lloadd.
I have a backend with starttls configure but with bad CN.
When I direct query the backend using ldapsearch with option -ZZ, I have the
following error:
ldap_start_tls: Connect error (-11)
additional info: (unknown error code)
But when I query the lloadd, which use same backend with olcBkLloadStartTLS to
critical. It's work...
On a tcpdump I can see the communication between backend and lloadd is not
using starttls. (cleartext). But it shouldn't (critical option)
cn: {1}ldap://ldap01.example.com
olcBkLloadBackendUri: ldap://ldap01.example.com
olcBkLloadNumconns: 10
olcBkLloadBindconns: 5
olcBkLloadRetry: 5000
olcBkLloadMaxPendingOps: 50
olcBkLloadMaxPendingConns: 10
olcBkLloadWeight: 1
olcBkLloadStartTLS: critical
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
https://bugs.openldap.org/show_bug.cgi?id=7981
Ondřej Kuzník <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=10254
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7981
Ondřej Kuzník <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CONFIRMED |IN_PROGRESS
--- Comment #5 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
https://git.openldap.org/openldap/openldap/-/merge_requests/763
Gone with another auxiliary objectclass but rereading the conversation, I guess
I'll adjust to use a subclass later.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10325
Issue ID: 10325
Summary: Variant uses overlays OID instead of contrib OID
(OLcfgOvAt instead of OLcfgCtAt) for configuration
attributes
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 variant contrib overlay uses the wrong base OID for its attributes, which
leads to OID duplication with DDS
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10327
Issue ID: 10327
Summary: Adding syncprov to cn=config can lock up server
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
As reported on openldap-technical[0], adding syncprov to a cn=config DB can
lock up the server. This happens when syncprov_db_otask is scheduled by
syncprov_db_open.
ITS#9045 has already dealt with this for config_back_entry_get, we can relax
this description and allow a config_back_search do the same. Even though it is
technically on a different thread than the main modification, AFAIK it is still
the only one running as the server is paused and the main modification is
paused waiting for it?
[0].
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
--
You are receiving this mail because:
You are on the CC list for the issue.