https://bugs.openldap.org/show_bug.cgi?id=10208
Issue ID: 10208
Summary: build test failure: test076-authid-rewrite (2.6.8
(RE26)
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: brett(a)gladserv.com
Target Milestone: ---
Testing RE26 on Gentoo Linux. Test 076 fails with "generic failure: internal
error: failed to init cipher 'rc4'"
>>>>> 00:07:19 Starting test076-authid-rewrite for mdb...
running defines.sh
Starting slapd on TCP/IP port 9011...
/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests
Using ldapsearch to check that slapd is running...
Checking whether DIGEST-MD5 is supported...
Adding schema and database...
Using ldapadd to populate the database...
Adding olcAuthzRegexp rule for static mapping...
Testing ldapwhoami as Manager...
ldap_sasl_interactive_bind: Local error (-2)
additional info: SASL(-1): generic failure: internal error: failed to
init cipher 'rc4'
ldapwhoami failed (254)!
>>>>> 00:07:20 Failed test076-authid-rewrite for mdb after 1 seconds
(exit 254)
make[2]: *** [Makefile:320: mdb-yes] Error 254
make[2]: Leaving directory '/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests'
make[1]: *** [Makefile:287: test] Error 2
make[1]: Leaving directory '/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests'
make: *** [Makefile:298: test] Error 2
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10209
Issue ID: 10209
Summary: OpenBSD Build failure (2.6.8 (RE26)
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: Other
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: brett(a)gladserv.com
Target Milestone: ---
Build failure on OpenBSD 7.2. NB: OpenBSD uses LibreSSL, not OpenSSL, and I
have no idea if that's supported, but configure should at least pick that up I
think.
libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c
tls_o.c -fPIC -DPIC -o .libs/tls_o.o
tls_o.c:228:19: error: use of undeclared identifier 'OPENSSL_INIT_NO_ATEXIT'
OPENSSL_init_ssl(OPENSSL_INIT_NO_ATEXIT, NULL);
^
1 error generated.
*** Error 1 in libraries/libldap (Makefile:432 'tls_o.lo')
*** Error 2 in libraries (Makefile:317 'all-common': @for i in liblutil
liblber liblunicode libldap librewrite ; do echo " Entering
...)
*** Error 2 in /home/bacs/openldap-OPENLDAP_REL_ENG_2_6 (Makefile:325
'all-common': @for i in include libraries clients servers tests doc ; ...)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10214
Issue ID: 10214
Summary: Reduce library dependencies
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
Currently, slapd links libsystemd to notify service state to systemd.
However, libsystemd link several unnecessary libraries, which increases
security risks.
The systemd documentation provides a method to send state notifications to
systemd using a simple protocol without the need to link against libsystemd.
https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html
I propose removing libsystemd and its depended libraries, similar to the
approach taken by OpenSSH.
Applying this fix reduced the following ten dependencies in the RHEL 8
environment.
- libsystemd.so.0
- libblkid.so.1
- libcap.so.2
- libgcc_s.so.1
- libgcrypt.so.20
- libgpg-error.so.0
- liblz4.so.1
- liblzma.so.5
- libmount.so.1
- librt.so.1
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10179
Issue ID: 10179
Summary: back-asyncmeta(5) man page incorrectly mentions
"rewrite"
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: nivanova(a)symas.com
Target Milestone: ---
Man page for back-asyncmeta mentions the rewrite options, yet asyncmeta does
not support the rewrite engine at the moment.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10164
Issue ID: 10164
Summary: back-meta hangs when used with dynlist overlay
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: ---
When back-meta is configured with the dynlist overlay, on a search request that
triggers dynlist, it will hang. This happens because of a bug in back-meta that
is only revealed when an overlay issues an internal operation while processing
a result or an entry, as dynlist does, as apposed to issuing it when the client
op is first received ( on the way "down" to the backend).
The issue is reproduced by configuring dynlist over a back-meta database, and
sending a subtree search request with the database suffix as dn.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10216
Issue ID: 10216
Summary: Channel binding enforced on AD with AD cert using
EDCSA-SHA384 fails
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
Secure LDAP connections to the target Windows server 2019 DC began failing
after the Windows Server DC certificate was updated to an Elliptic Curve Public
Key (384 bits) with the sha384ECDSA signature algorithm and sha384 signature
hash algorithm specified. Â
The connections were previously successful when the Windows server DC
certificate specified an RSA Public Key certificate with signature algorithm
sha256RSA and signature hash algorithm sha256 specified. Â
Once the Windows server domain controller certificate is upgraded to the ECC
public key, subsequent secure ldap connection attempts fail.
If channel binding is turned off on the Windows AD target server, secure ldap
connections will succeed using starttls.
If Windows server domain controller certificate is upgraded to ECC public key
and ldap channel binding is enforced, subsequent secure ldap connection
attempts fail with this error message:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
    additional info: 80090346: LdapErr: DSID-0C09070F, comment:
AcceptSecurityContext error, data 80090346, v4563
Expected results:
Kerberos SASL should work with STARTTLS even when AD certificate is ECC and
SASL_CBINDING is set to "tls-endpoint"
Actual results:
Kerberos SASL only works with STARTTLS even when AD certificate is RSA and
SASL_CBINDING is set to "tls-endpoint"; it fails when AD certificate is ECC
Additional information:
According to the OpenSSL maintainer, there might be a bug in the OpenLDAP code:
it uses EVP_get_digestbynid() to find a digest algorithm based on the signature
algorithm, but there might be no such mapping in EC compared to the RSA case.
OpenLDAP needs to use OBJ_find_sigid_algs() to find the right algorithm.
Possibly, this is the failing code:
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/…
Instead of X509_get_signature_nid() OpenLDAP code probably should call
something like OBJ_find_sigid_algs(X509_get_signature_nid(cert), &md_nid,
&pk_nid).
The former only supports mapping for a few known signature algorithms, but
everything did work, most likely due to a fallback to sha256 in case the digest
wasn't really found.
Judging by https://github.com/openssl/openssl/issues/14278 and
https://github.com/openssl/openssl/issues/14467, a better API is coming but not
currently available (and as it was in the state for a few years, it probably
won't be coming soon)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10212
Issue ID: 10212
Summary: read-only tools may use wrong meta page
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
On a quiescent database that's only used for read-only txns, the txnid won't be
initialized so it remains set to zero. Then only meta page zero will get used,
even if page one is newer. Thus all information retrieved will be stale by one
txn.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9921
Issue ID: 9921
Summary: Tautology in clients/tools/common.c:print_vlv()
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm…
contains:
tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
ldif ? "vlvResult" : "vlvResult", buf, rc );
The second parameter is always vlvResult, irrespective of the value of ldif.
--
You are receiving this mail because:
You are on the CC list for the issue.