https://bugs.openldap.org/show_bug.cgi?id=9436
Issue ID: 9436
Summary: OpenSSL 3.0: libldap uses depreciated functions
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
OpenLDAP master fails to build against OpenSSL 3.0 alpha when "no-deprecated"
is specified.
Currently hitting these errors:
./.libs/libldap.so: undefined reference to `SSL_get_peer_certificate'
./.libs/libldap.so: undefined reference to `PEM_read_bio_DHparams'
./.libs/libldap.so: undefined reference to `ERR_get_error_line'
./.libs/libldap.so: undefined reference to `DH_free'
./.libs/libldap.so: undefined reference to `SSL_CTX_set_tmp_dh'
Notes:
SSL_get_peer_certificate is SSL_get1_peer_certificate in 3.0.0
SSL_CTX_set_tmp_dh should be replaced as follows:
# define SSL_CTX_set_tmp_dh(ctx,dh) \
SSL_CTX_ctrl(ctx,SSL_CTRL_SET_TMP_DH,0,(char *)(dh))
Have to dig deeper for:
PEM_read_bio_DHparams
ERR_get_error_line
DH_free
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9832
Issue ID: 9832
Summary: back-monitor crash when sizelimit in operation
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: ---
If a back-monitor search gets a failure in send_search_entry(), e.g. due to
sizelimit being reached, a pending server pause, etc., it will try to call
monitor_cache_release( mi, e ) where e == NULL instead of the correct entry to
release.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9460
Issue ID: 9460
Summary: Drop support for OpenSSL older than 1.1.1
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
OpenSSL no longer supports the 1.0.2 series and specifically notes it should
not be used:
"All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of
support and should not be used."
Currently configure checks for 1.0.2 or higher.
OpenSSL 1.1.1 is supported through 11 Sep 2023.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9887
Issue ID: 9887
Summary: Offer to mirror OpenLDAP
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: mirrors(a)jevincanders.net
Target Milestone: ---
Greetings,
We're from Jevin Canders, a hosting company based in New York (servers are in
Buffalo).
We're wondering if you wanted/needed another US mirror. We're already mirroring
other open source projects, including Kali Linux and F-Droid. As of next week
(tentatively), our mirror server will have a 20 Gbps pipe to work with, so
we'll be able to handle new projects.
Let us know if you have any questions, concerns, or requests.
Sincerely,
Josh Anders and Kevin Croissant
JC Mirrors Team
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9898
Issue ID: 9898
Summary: slapd-addel.c contains invalid struct initialization
which does not compile on HP-UX aCC
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: Other
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael.osipov(a)siemens.com
Target Milestone: ---
My compiler (cc: HP C/aC++ B3910B A.06.29 [Oct 18 2016]) gives me:
/opt/aCC/bin/aCC -Ae -g -I../../include -I../../include -I/opt/ports/include
-I/opt/ports/include -c -o slapd-addel.o slapd-addel.c
"slapd-addel.c", line 68: error #2029: expected an expression
LDIFRecord record = {};
^
"slapd-addel.c", line 70: error #2029: expected an expression
struct berval bv = {};
^
This is invalid C code, it can be easily solved by using "{0}" and the code
does compile.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9892
Issue ID: 9892
Summary: LDAP_TXN_SPECIFY assumes cleanup responsibility for
writes but never performs it
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 TXN extop is accepted and the client sends some write ops, the cleanup
path is skipped within do_modify/do_add/... however the data is never actually
freed when the transaction is being settled (regardless of whether it was
committed successfully or aborted).
Confirmed to happen with do_modify by tests/scripts/lloadd/test007-coherence,
for others it's my assumption based on reading the code.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9880
Issue ID: 9880
Summary: reqStart filter with trailing zeros is truncated,
which breaks certain searches
Product: OpenLDAP
Version: 2.5.12
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: ---
Note: ITS#9358 seems to address this very issue, but it doesn't seem to help
this particular case.
Certain range searches with reqStart on the changelog don't work as expected.
For example:
(!(reqStart<=20220707123456.000000Z))
The idea here is to grab all entries strictly greater than the timestamp. But
slapd truncates zeros in this filter, rewriting it to:
(!(reqStart<=20220707123456Z))
As a result, the reqStart=20220707123456.000000Z entry is the first match since
it is greater than 20220707123456Z, which is not the desired behavior.
I was able to reproduce this issue on 2.5.12 as follows:
1) Start the test043-delta-syncrepl test, let it run almost to the end so that
it makes many changes, and then hit ^Z to suspend the script. I waited until
one of the last occurrences of "Waiting 7 seconds for syncrepl to receive
changes".
2) pkill -CONT -f slapd to restart slapd (but not the test script)
3) ldapsearch -x -h localhost:9011 -b cn=log objectclass=top | grep
'^dn:.*.000000Z'
Look for a change with all trailing zeros. It's not as rare as one might think,
I saw at least one trailing-zeros change in two consecutive runs of the test
script. I suppose you could also just create an entry with all trailing zeros
in the accesslog :-)
4) Run a range search to only return changes after that change (I used -z 1 and
-s one so that it would only give me one result):
ldapsearch -x -z 1 -h localhost:9011 -b cn=log -s one
'(!(reqStart<=20220708012121.000000Z))'
If you see the same entry, then the problem is present.
5) Even if you can't have an accesslog entry with all trailing zeros, you can
still do the above search verbatim and look at the slapd log file
testrun/slapd.1.log:
62c7873f.145b4396 0x7fabf14c9700 conn=1011 op=1 SRCH base="cn=log" scope=1
deref
=0 filter="(!(reqStart<=20220708012121Z))"
The filter being rewritten in the server log seems to indicate that trailing
zeros are being truncated somewhere.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9897
Issue ID: 9897
Summary: ldapcompare return FALSE when dynlist in use
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: sdalu(a)sdalu.com
Target Milestone: ---
The server configuration enable dynlist with:
overlay dynlist
dynlist-attrset groupOfURLs memberURL member
Entry is:
dn: cn=Admins,ou=Services,ou=Members,dc=zog,dc=com
member: uid=foo,ou=People,dc=zog,dc=com
cn: Admins
objectClass: groupOfNames
The ldap compare will return false, was expected true
ldapcompare -x cn=Admins,ou=Services,ou=Members,dc=zog,dc=com
member:uid=foo,ou=People,dc=zog,dc=com
Now if I comment the dynlist-attrset directive, I will get TRUE for the same
ldapcompare request
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9904
Issue ID: 9904
Summary: A Potential NPD
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 1157401338(a)qq.com
Target Milestone: ---
Created attachment 911
--> https://bugs.openldap.org/attachment.cgi?id=911&action=edit
diagram of NPD
Hi, I found a NPD bug in the project source code of ldap, and I have shown the
execution sequence of the program that may have generated the bug on a
diagram,which is added to the attachment
The red text illustrates the steps that created the bug
the red arrows represent the call relationships
the file path can be seen in the blue framed section.
additionally,at step 4 I do not expand more detail about why function
ber_memalloc_x can return null(actually it can be seen as function malloc and
the reason ber_memalloc_x return null is same with malloc),because there are
many code snippet can be found in project source code that judge whether
ber_memalloc_x return null and make further process if return value equal to
null.
I look forward to your reply and thank you very much for your patience!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9901
Issue ID: 9901
Summary: Fix non-standard printf arguments in liblbert and
libldap
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: michael.osipov(a)siemens.com
Target Milestone: ---
Created attachment 910
--> https://bugs.openldap.org/attachment.cgi?id=910&action=edit
Patch gainst source tarball
As a followup to Bug 9898 and Bug 9899 I have played around with LLVM 13 and
"-std=c17 -pedantic -Wall" it fails to compile several files. Find a patch
attached which makes it standards compliant.
--
You are receiving this mail because:
You are on the CC list for the issue.