https://bugs.openldap.org/show_bug.cgi?id=10084
Issue ID: 10084
Summary: Move away from DIGEST-MD5 as a default in the test
suite
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: ---
cyrus-sasl seem on the verge or removing the DIGEST-MD5 mechanism from 2.2
onwards. As such we should update our defaults in a couple of our test scripts
for master/2.7 at least. Are SCRAM mechanisms the go-to these days?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10207
Issue ID: 10207
Summary: configure: Syntax error: Unterminated quoted string
(2.6.8 (RE26))
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: FreeBSD
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: brett(a)gladserv.com
Target Milestone: ---
Created attachment 1017
--> https://bugs.openldap.org/attachment.cgi?id=1017&action=edit
Patch for configure.ac
Testing RE26 (2.6.8)
On FreeBSD and NetBSD, configure fails with the following error:
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
./configure: 13865: Syntax error: Unterminated quoted string
Patch for configure.ac attached.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10210
Issue ID: 10210
Summary: ldapurl manpage references options that no longer
exist
Product: OpenLDAP
Version: 2.6.7
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: ---
-h ldaphost
Set the host.
-p ldapport
Set the TCP port.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10195
Issue ID: 10195
Summary: permissive modify control without value
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: lesignor(a)cirad.fr
Target Milestone: ---
Hello,
A windows ldap client (dotnet) format the request with oid permissive modify
control like this :
00d0 30 84 00 00 00 1e 04 17 ........0.......
00e0 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 2e 31 1.2.840.113556.1
00f0 2e 34 2e 31 34 31 33 01 01 ff 04 00 .4.1413.....
The last 2 bytes 04 00 seems to indicate no value (length of value = 0 ?).
With openldap 2.4.x this request was accepted.
With openldap 2.5.x or openldap 2.6.x, this request is rejected for invalid
protocol with error message : permissiveModify control value not absent
With ldapmodify from openldap, the same request is formatted without the last 2
bytes and is accepted.
Could it be possible to accept request with control without value formatted
with 04 00 to indicate no value ?
It will help to migrate from openldap 2.4.x to 2.5.x or 2.6.x
Thanks
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10205
Issue ID: 10205
Summary: SSL handshake blocks forever in async mode if server
unaccessible
Product: OpenLDAP
Version: 2.5.17
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: regtube(a)hotmail.com
Target Milestone: ---
When ldaps:// scheme is used to connect to currently unaccessible server with
LDAP_OPT_CONNECT_ASYNC and LDAP_OPT_NETWORK_TIMEOUT options set, it blocks
forever on SSL_connect.
Here is a trace:
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP winserv.test.net:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.56.2:636
ldap_pvt_connect: fd: 3 tm: 30 async: -1
ldap_ndelay_on: 3
attempting to connect:
connect errno: 115
ldap_int_poll: fd: 3 tm: 0
ldap_err2string
[2024-04-25 15:41:27.112] [error] [:1] bind(): Connecting (X)
[2024-04-25 15:41:27.112] [error] [:1] err: -18
ldap_sasl_bind
ldap_send_initial_request
ldap_int_poll: fd: 3 tm: 0
ldap_is_sock_ready: 3
ldap_ndelay_off: 3
TLS trace: SSL_connect:before SSL initialization
TLS trace: SSL_connect:SSLv3/TLS write client hello
Looks like it happens because non-blocking mode is cleared from the socket
(ldap_ndelay_off) after the first poll for write, and non-blocking mode is
never restored before attempt to do tls connect, because of the check that
assumes that non-blocking mode has already been set for async mode:
if ( !async ) {
/* if async, this has already been set */
ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 );
}
while in fact it was cleared.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10203
Issue ID: 10203
Summary: no pkgconfig file included for liblmdb
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: otto(a)drijf.net
Target Milestone: ---
liblmdb does not ship with a pkgconfig file. More and more build systems rely
on presense of a pkgconfig file, so it would be nice if liblmdb installed
oneone. An example:
prefix=/usr/local
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
Name: lmdb
Description: Lightning memory-mapped database: key-value data store
URL: https://www.symas.com/symas-embedded-database-lmdb
Version: 0.9.32
Libs: -L${libdir} -llmdb
Cflags: -I${includedir}
Thanks.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8613
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=10167
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10167
Issue ID: 10167
Summary: slapo-memberof should have a way of reacting to a
member entry being added after group referencing it
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If a group (with member: values) is added before the member entries exist, the
memberof values never get populated. This can happen e.g. during replication.
No idea how it meshes with the refint functionality of memberof if it's indeed
reconcilable at all.
Silly example (Hird's memberof will be empty):
```ldif
dn: cn=GNU,ou=Groups,dc=example,dc=com
objectClass: groupOfNames
member: cn=Hurd,ou=Groups,dc=example,dc=com
dn: cn=Hurd,ou=Groups,dc=example,dc=com
objectClass: groupOfNames
member: cn=Hird,ou=Groups,dc=example,dc=com
member: cn=Roger Rabbit,ou=People,dc=example,dc=com
dn: cn=Hird,ou=Groups,dc=example,dc=com
objectClass: groupOfNames
member: cn=Tweety Bird,ou=People,dc=example,dc=com
member: cn=Hurd,ou=Groups,dc=example,dc=com
```
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10161
Issue ID: 10161
Summary: Move nested group support to its own overlay
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: enhancement
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Adding the feature to dynlist has made that code overly complex, along with
killing performance.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10193
Issue ID: 10193
Summary: Asyncmeta starts more than one timeout loop per
database
Product: OpenLDAP
Version: 2.6.7
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: ---
By design, there should be always exactly one timeout loop task per database,
it is a balance to make sure timeout checks do not throttle traffic processing.
For some reason, there seems to be more than one. This is only visible if slapd
is started with -dasyncmeta log level.
--
You are receiving this mail because:
You are on the CC list for the issue.