https://bugs.openldap.org/show_bug.cgi?id=10039
Issue ID: 10039
Summary: configure fails to detect
SSL_export_keying_material_early with LibreSSL
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: orbea(a)riseup.net
Target Milestone: ---
Created attachment 957
--> https://bugs.openldap.org/attachment.cgi?id=957&action=edit
config.log
When configuring OpenLDAP using --with-tls=openssl with LibreSSL the configure
will fail to detect SSL_export_keying_material_early since LibreSSL doesn't
support this function yet. However OpenLDAP doesn't actually use this function
so this can be easily solved by checking for SSL_library_init which is a more
standard function which both OpenSSL and LibreSSL support which OpenLDAP
actually uses in libraries/libldap/tls_o.c.
checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... yes
checking for openssl/ssl.h... yes
checking for SSL_export_keying_material_early in -lssl... no
configure: error: Could not locate TLS/SSL package
Other than this the build succeeds correctly with at least LibreSSL 3.7.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9995
Issue ID: 9995
Summary: Potential memory leak in clients/tools/ldapdelete.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in ldapdelete.c line 384.Calling ldap_search_ext_s()
without calling ldap_msgfree() to free the memory will cause a memory leak.
Doc says "Note that res parameter of ldap_search_ext_s() and
ldap_search_s() should be freed with ldap_msgfree() regardless of return value
of these functions." in
https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10032
Issue ID: 10032
Summary: at_add returns a free'd pointer on error
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
When an invalid schema is provided (e.g. the current
./servers/slapd/schema/msuser.schema of memberof/dynlist is loaded already),
at_add() hits error handling and frees at->at_oid, but that string is being
returned in *err. A fix is coming.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9989
Issue ID: 9989
Summary: «make clean» shall not delete
libraries/libldap/ldap.pc and
libraries/liblber/lber.pc
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
«./configure» and «./config.status» do create ./libraries/libldap/ldap.pc,
./libraries/liblber/lber.pc, while «make clean» deletes both .pc files.
«make install» fails, if ./libraries/libldap/ldap.pc or
./libraries/liblber/lber.pc are missing.
«./configure && make clean && make depend && make install» is a valid workflow
for many other (autoconf/automake based) projects.
./libraries/libldap/ldap.pc and ./libraries/liblber/lber.pc shall be deleted by
«make distclean», and kept by «make clean».
See also https://www.gnu.org/prep/standards/html_node/Standard-Targets.html for
the idea behind «make clean» vs «make distclean».
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10028
Issue ID: 10028
Summary: crash with pwdMinDelay
Product: OpenLDAP
Version: 2.5.14
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
slapd crash when using pwdMinDelay of ppolicy.
The cause is that slap_timestamp() writes to undefined area.
It has already been fixed.
backtrace:
```
(gdb) bt
#0 0x00007f2c70bdbaff in raise () from /lib64/libc.so.6
#1 0x00007f2c70baeea5 in abort () from /lib64/libc.so.6
#2 0x00007f2c70baed79 in __assert_fail_base.cold.0 () from /lib64/libc.so.6
#3 0x00007f2c70bd4456 in __assert_fail () from /lib64/libc.so.6
#4 0x0000000000499fdf in entry_schema_check (op=<optimized out>,
op@entry=0x7f2c2a9a9ff0,
e=<optimized out>, e@entry=0x7f2c20001d30, oldattrs=<optimized out>,
oldattrs@entry=0x7f2c20001d30, manage=0, add=add@entry=0,
socp=socp@entry=0x7f2c2a9a99d8,
text=0x7f2c2a9a9f30, textbuf=0x7f2c2a9a9b40 "", textlen=256)
at ../../../servers/slapd/schema_check.c:89
#5 0x00000000004f5dc1 in mdb_modify_internal (op=<optimized out>,
op@entry=0x7f2c2a9a9ff0,
tid=tid@entry=0x11dc8c0, modlist=<optimized out>, e=<optimized out>,
e@entry=0x7f2c2a9a9ac0,
text=text@entry=0x7f2c2a9a9f30, textbuf=textbuf@entry=0x7f2c2a9a9b40 "",
textlen=256)
at ../../../../servers/slapd/back-mdb/modify.c:419
#6 0x00000000004f6cfa in mdb_modify (op=0x7f2c2a9a9ff0, rs=0x7f2c2a9a9f10)
at ../../../../servers/slapd/back-mdb/modify.c:714
#7 0x00000000004d5833 in overlay_op_walk (op=0x7f2c2a9a9ff0,
rs=0x7f2c2a9a9f10,
which=<optimized out>, oi=0xfc1a00, on=0x0) at
../../../servers/slapd/backover.c:706
#8 over_op_func (op=0x7f2c2a9a9ff0, rs=0x7f2c2a9a9f10, which=op_modify)
at ../../../servers/slapd/backover.c:766
#9 0x00007f2c6be56a95 in ppolicy_bind_response (op=<optimized out>,
rs=0x7f2c2a9aa730)
at ../../../../servers/slapd/overlays/ppolicy.c:1827
#10 0x0000000000475878 in slap_response_play (op=0x7f2c201039a0,
rs=0x7f2c2a9aa730)
at ../../../servers/slapd/result.c:567
#11 send_ldap_response (op=op@entry=0x7f2c201039a0, rs=rs@entry=0x7f2c2a9aa730)
at ../../../servers/slapd/result.c:642
#12 0x0000000000475f2c in slap_send_ldap_result (op=0x7f2c201039a0,
rs=0x7f2c2a9aa730)
at ../../../servers/slapd/result.c:918
#13 0x000000000052b6cf in mdb_bind (op=0x7f2c201039a0, rs=0x7f2c2a9aa730)
at ../../../../servers/slapd/back-mdb/bind.c:148
#14 0x00000000004d5833 in overlay_op_walk (op=0x7f2c201039a0,
rs=0x7f2c2a9aa730,
which=<optimized out>, oi=0xfc1a00, on=0x0) at
../../../servers/slapd/backover.c:706
#15 over_op_func (op=0x7f2c201039a0, rs=0x7f2c2a9aa730, which=op_bind)
at ../../../servers/slapd/backover.c:766
#16 0x00000000004824f2 in fe_op_bind (op=0x7f2c201039a0, rs=0x7f2c2a9aa730)
at ../../../servers/slapd/bind.c:383
#17 0x00000000004822ea in do_bind (op=0x7f2c201039a0, rs=0x7f2c2a9aa730)
at ../../../servers/slapd/bind.c:206
#18 0x0000000000466847 in connection_operation (ctx=<optimized out>,
ctx@entry=0x7f2c2a9aa9b8,
arg_v=arg_v@entry=0x7f2c201039a0) at
../../../servers/slapd/connection.c:1113
#19 0x0000000000465ec1 in connection_read_thread (ctx=<optimized out>,
argv=0x11)
at ../../../servers/slapd/connection.c:1265
#20 0x00007f2c72d5ea22 in ldap_int_thread_pool_wrapper (xpool=<optimized out>)
at ../../../libraries/libldap/tpool.c:1053
#21 0x00007f2c70f5b1cf in start_thread () from /lib64/libpthread.so.0
#22 0x00007f2c70bc6e73 in clone () from /lib64/libc.so.6
```
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9997
Issue ID: 9997
Summary: Potential memory leak in servers/slapd/syncrepl.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in syncrepl.c line 605.Calling ldap_search_ext_s()
without calling ldap_msgfree() to free the memory will cause a memory leak.
Doc says "Note that res parameter of ldap_search_ext_s() and
ldap_search_s() should be freed with ldap_msgfree() regardless of return value
of these functions." in
https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9990
Issue ID: 9990
Summary: Part of the ITS#8698 fix breaks exop overlays that set
a callback
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: subbarao(a)computer.org
Target Milestone: ---
We have a password exop overlay that sets up a callback, which has stopped
working when upgrading to 2.5.13. and I tracked it down to a change to
servers/slapd/passwd.c implemented as part of the fix for ITS#8698:
https://git.openldap.org/openldap/openldap/-/merge_requests/304/diffs?commi…
It appears that the intent of this change was to loop through the o_callback
list and only remove the cb callback created in this section of the code. But
that isn't necessary because the cb callback never gets added to the original
list. With this change, line 295 clobbers the original o_callback list which
never gets restored -- that's why our exop overlay stopped working.
Fortunately, the fix is very simple -- just revert this part of the change. The
original code already saved/restored the o_callback list properly.
When I reverted this part of the change, our exop overlay resumed working, and
the rest of the ITS#8698 functionality (messages from the pwdCheckModule module
being returned to the user) also worked as expected.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10035
Issue ID: 10035
Summary: TLSv1.3 cipher suites can be set incorrectly
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: ipuleston(a)sonicwall.com
Target Milestone: ---
I noticed that, on the client side, when I use LDAP_OPT_X_TLS_CIPHER_SUITE to
set an OpenSSL cipher-suites list that contains a TLSv1.3 cipher suite, that
may or may not get set correctly, depending on where it is located in the list.
The following is what I am seeing with TLS versions 1.2 and 1.3 enabled:
If I set this cipher-suites list:
"3DES:TLS_AES_128_GCM_SHA256:!eNULL"
Then WireShark shows shows it offering these ciphers in the TLS Client Hello,
which is correct (the single given TLSv1.3 suite, plus 6 using 3-DES):
Cipher Suites (7 suites)
Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
However, if I set this cipher-suites list:
"!eNULL:3DES:TLS_AES_128_GCM_SHA256"
Then it now incorrectly offers two additional TLSv1.3 suites:
Cipher Suites (9 suites)
Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Those first three are all of the TLSv3 ciphers supported by OpenSSL in this
system.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10003
Issue ID: 10003
Summary: Potential Use After Free in libraries/libldap/open.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential Use After Free in open.c line 590.
Doc says "Once it(ldap_unbind) is called, the connection to the LDAP server
is closed, and the ld structure is invalid."
in
https://www.openldap.org/software/man.cgi?query=ldap_unbind_ext&apropos=0&s…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9998
Issue ID: 9998
Summary: Potential memory leak in tests/progs/slapd-mtread.c
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: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in slapd-mtread.c line 520.Calling ldap_search_ext_s()
without calling ldap_msgfree() to free the memory will cause a memory leak.
Doc says "Note that res parameter of ldap_search_ext_s() and
ldap_search_s() should be freed with ldap_msgfree() regardless of return value
of these functions." in
https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0…
--
You are receiving this mail because:
You are on the CC list for the issue.