https://bugs.openldap.org/show_bug.cgi?id=10509
Issue ID: 10509
Summary: 2.7: Feature notes for announcement file
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: ---
Add feature notes for the 2.7 announcement file
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
https://bugs.openldap.org/show_bug.cgi?id=7347
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.
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=8852
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.
https://bugs.openldap.org/show_bug.cgi?id=8826
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.
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.
https://bugs.openldap.org/show_bug.cgi?id=10364
Issue ID: 10364
Summary: back-asyncmeta should process a notice-of-disconnect
and close the target connection
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
At present, back-asyncmeta discards all unsolicited messages, received on the
target connections. It should instead process Notice-of-Disconnection messages
and close the connections on which they were received.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10363
Issue ID: 10363
Summary: Implement a target connection time-to-live in
asyncmeta
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Implement a feature that limits the maximum time before a target connection is
reset, even if it is not idle - conn-ttl. To avoid too many target connections
timing out at once, a minimum reset interval per target should also be
configurable. So, a configuration of:
conn-ttl 5s 5s
would mean connections have a 5 seconds time-to-live, but a connection should
be reset no more frequently that once every 5 seconds per target.
This feature was requested by a customer.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10280
Issue ID: 10280
Summary: Combining positive & negated filters doesn't work with
dynlist
Product: OpenLDAP
Version: 2.5.18
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: code(a)pipoprods.org
Target Milestone: ---
The directory contains 3 users & 2 groups.
user1 is in group1, user2 is in group2, user3 isn't is any group.
Filter [1] matches users that are either:
- member of group1
- member of group2
✅ It returns user1 & user2
Filter [2] matches user that are:
- not member of group1 nor group2
✅ It returns user3
Filter [3] should match users that are either:
- member of group1
- member of group2
- not member of group1 nor group2
❌ It should return the 3 users but only returns users matched by the first part
of the filter (whatever the first part, if we swap both parts we get the
complementary search results)
Filter [1]:
(|(memberOf=cn=group1,ou=example-groups,dc=example,dc=com)(memberOf=cn=group2,ou=example-groups,dc=example,dc=com))
Filter [2]:
(!(|(memberOf=cn=group1,ou=example-groups,dc=example,dc=com)(memberOf=cn=group2,ou=example-groups,dc=example,dc=com)))
Filter [3]:
(|(memberOf=cn=group1,ou=example-groups,dc=example,dc=com)(memberOf=cn=group2,ou=example-groups,dc=example,dc=com)(!(|(memberOf=cn=group1,ou=example-groups,dc=example,dc=com)(memberOf=cn=group2,ou=example-groups,dc=example,dc=com))))
Here's my dynlist config:
```
dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcDynListConfig
olcOverlay: {2}dynlist
olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames
structuralObjectClass: olcDynListConfig
entryUUID: 7df8328a-fd72-103e-82df-6fed25d5f6c8
creatorsName: cn=config
createTimestamp: 20240902122741Z
entryCSN: 20240902122741.257759Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20240902122741Z
```
Here's a LDIF to initialise directory contents:
```
dn: ou=example-groups,dc=example,dc=com
changetype: add
objectClass: organizationalUnit
ou: example-groups
dn: ou=example-users,dc=example,dc=com
changetype: add
objectClass: organizationalUnit
ou: example-users
dn: uid=user1,ou=example-users,dc=example,dc=com
changetype: add
objectClass: inetOrgPerson
cn: User
sn: One
uid: user1
dn: uid=user2,ou=example-users,dc=example,dc=com
changetype: add
objectClass: inetOrgPerson
cn: User
sn: Two
uid: user2
dn: uid=user3,ou=example-users,dc=example,dc=com
changetype: add
objectClass: inetOrgPerson
cn: User
sn: Three
uid: user3
dn: cn=group1,ou=example-groups,dc=example,dc=com
changetype: add
objectClass: groupOfNames
cn: group1
member: uid=user1,ou=example-users,dc=example,dc=com
dn: cn=group2,ou=example-groups,dc=example,dc=com
changetype: add
objectClass: groupOfNames
cn: group2
member: uid=user2,ou=example-users,dc=example,dc=com
```
--
You are receiving this mail because:
You are on the CC list for the issue.