https://bugs.openldap.org/show_bug.cgi?id=9884
Issue ID: 9884
Summary: Document "set" patterns in ACLs
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: ---
The slapd.access(5) man page has this exceptionally unhelpful line where sets
are concerned:
"The statement set=<pattern> is undocumented yet."
Even if it is an experimental feature, it should still be documented on how it
is meant to operate.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9726
Issue ID: 9726
Summary: Admin guide and man pages need better documentation on
disabling syslog
Product: OpenLDAP
Version: 2.6.0
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: ---
2.6.0 added the new feature allowing using a logfile for all debug/loglevel
messages and bypassing syslog entirely. However, there is no documentation on
the new settings or examples of how to do this in the admin guide, and the man
page sections on the new parameters for the logfile side do not note at
when/how they enable bypassing syslog.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10313
Issue ID: 10313
Summary: 3-way multimaster oathHOTPCounter attribute update
code missing
Product: OpenLDAP
Version: 2.6.6
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: agrru01(a)gmail.com
Target Milestone: ---
I posted on openldap technical mail list and got a response saying I should
file a feature request.
I am using a 3-way multimaster syncrepl setup with the slapo-otp module. My
problem is that when authenticating with a user using HOTP, the attribute
oathHOTPCounter only updates the value on the target ldap instance. This means
the other two ldap instances do not get the updated HOTP-counter value and
therefore will allow authentication using the same HOTP code.
Interestingly enough, if I manually edit the oathHOTPCounter value it
synchronizes with the other masters.
Please see the technical mail list discussion:
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10391
Issue ID: 10391
Summary: Add proper compiler/linker flag for threading support
on HP-UX
Product: OpenLDAP
Version: 2.6.10
Hardware: Other
OS: Other
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: michael.osipov(a)innomotics.com
Target Milestone: ---
Created attachment 1085
--> https://bugs.openldap.org/attachment.cgi?id=1085&action=edit
Patch against master
If an application uses a thread-enabled library or the application itself is
thread enabled it is imperative on HP-UX to use the -mt flag through out build.
The compiler will transform into proper -D and -l flags.
From the manpage:
-mt Sets various -D flags to enable multi-threading. Also
sets -lpthread. +Oopenmp automatically implies -mt.
For details see HP C/aC++ Online Programmer's Guide.
Find a Git-formatted patch attached.
Sample output:
libtool: link: /opt/aCC/bin/aCC -AC99 +We901 -o ldapsearch ldapsearch.o
common.o ldsversion.o -L/opt/ports/lib/hpux32
../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.a
-L/opt/ports/lib
/var/tmp/ports/work/openldap-threading-hpux/libraries/liblber/.libs/liblber.a
../../libraries/liblber/.libs/liblber.a /opt/ports/lib/hpux32/libsasl2.so -ldl
-lssl -lcrypto -mt -Wl,+b -Wl,/opt/ports/lib/hpux32
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10390
Issue ID: 10390
Summary: ldif_parse_line2 calculates an incorrect length of the
attribute type
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
When parsing a line containing an attribute name and a value, e.g "carLicence
: 12344", ldif_parse_line2 calculates the type length incorrectly. It is not
clear if this affects any existing code or tools at the moment, but should be
fixed.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10388
Issue ID: 10388
Summary: ldif_parse_line2 is not compliant with RFC2849
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
RFC2849:
Any
value that contains characters other than those defined as
"SAFE-CHAR", or begins with a character other than those
defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded.
Other values MAY be base-64 encoded.
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F /
%x21-39 / %x3B / %x3D-7F
; any value <= 127 except NUL, LF, CR,
; SPACE, colon (":", ASCII 58 decimal)
; and less-than ("<" , ASCII 60 decimal)
However, if the value is not base64 encoded, ldif_parse_line2 (and consequently
ldap_parse_ldif_record_x) uses isspace() to just skip any white-space
characters at the beginning of at attribute value, icl. tabs. According to the
RFC, however, such characters are acceptable. In addition, it does not return
an error on LF or CR, just skips them.
On the one hand, LDIFs are supposed to be human readable, and fixing this issue
may lead to unexpected problems (e.g a stray tab being added to the attribute
value). On the other hand, the standard does not exclude %x01-09 and %x0B-0C as
valid characters for a non-encoded value.
How should we proceed?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10353
Issue ID: 10353
Summary: No TLS connection on Windows because of missing
ENOTCONN in socket.h
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: julien.wadel(a)belledonne-communications.com
Target Milestone: ---
On Windows, the TLS connection cannot be done and we get the connection error:
Can't contact LDAP server.
=> Connections are done with WSAGetLastError().
After getting WSAEWOULDBLOCK, the connection is not restart because of the
state WSAENOTCONN that is not known.
OpenLDAP use ENOTCONN that is set to 126 by "ucrt/errno.h" while WSAENOTCONN
is 10057L.
Adding #define ENOTCONN WSAENOTCONN
like for EWOULDBLOCK resolve the issue.
Reference commit on external project:
https://gitlab.linphone.org/BC/public/external/openldap/-/commit/62fbfb12e8…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10401
Issue ID: 10401
Summary: liblber: undefined shift of -1 in ber_decode_int()
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Report from curl project. Full info here
https://gist.github.com/bagder/44a0711fa1989951f2a2395fe992530e
Relevant stack trace:
[Environment]
UBSAN_OPTIONS=exitcode=77:print_stacktrace=1:silence_unsigned_overflow=1
+----------------------------------------Release Build
Stacktrace----------------------------------------+
Command: /mnt/scratch0/clusterfuzz/resources/platform/linux/unshare -c
-n
/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_4cc8f5a06444eef5b5b6682762bec8608d45b81b/revisions/curl_fuzzer_ldap
-rss_limit_mb=2560 -timeout=60 -runs=100
/mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-1364ab2dfa120fe4460381a08f4f158f8d47a30c
Time ran: 0.14911556243896484
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 1947994398
INFO: Loaded 1 modules (211579 inline 8-bit counters): 211579
[0x559e5bb87a40, 0x559e5bbbb4bb),
INFO: Loaded 1 PC tables (211579 PCs): 211579
[0x559e5bbbb4c0,0x559e5bef5c70),
/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_4cc8f5a06444eef5b5b6682762bec8608d45b81b/revisions/curl_fuzzer_ldap:
Running 1 inputs 100 time(s) each.
Running:
/mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-1364ab2dfa120fe4460381a08f4f158f8d47a30c
decode.c:316:21: runtime error: left shift of negative value -1
#0 0x559e5b730e08 in ber_decode_int
curl_fuzzer/build/openldap/src/openldap_external/libraries/liblber/decode.c:316:21
#1 0x559e5b730c5d in ber_get_int
curl_fuzzer/build/openldap/src/openldap_external/libraries/liblber/decode.c:293:9
#2 0x559e5b6e60f3 in try_read1msg
curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:592:7
#3 0x559e5b6e60f3 in wait4msg
curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:393:12
#4 0x559e5b6e60f3 in ldap_result
curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:120:7
#5 0x559e5af804d6 in oldap_connecting curl/lib/openldap.c:826:10
#6 0x559e5aead984 in protocol_connecting curl/lib/multi.c:1794:14
#7 0x559e5aead984 in multi_runsingle curl/lib/multi.c:2510:16
#8 0x559e5aeacd4f in curl_multi_perform curl/lib/multi.c:2791:18
#9 0x559e5ae7fb38 in fuzz_handle_transfer(fuzz_data*)
curl_fuzzer/curl_fuzzer.cc:419:5
#10 0x559e5ae7eff0 in LLVMFuzzerTestOneInput
curl_fuzzer/curl_fuzzer.cc:97:3
#11 0x559e5add608d in fuzzer::Fuzzer::ExecuteCallback(unsigned char
const*, unsigned long)
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13
#12 0x559e5adc0e02 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char
const*, unsigned long)
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:329:6
#13 0x559e5adc6cd0 in fuzzer::FuzzerDriver(int*, char***, int
(*)(unsigned char const*, unsigned long))
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:865:9
#14 0x559e5adf2802 in main
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#15 0x7c4beb5b7082 in __libc_start_main
/build/glibc-LcI20x/glibc-2.31/csu/libc-start.c:308:16
#16 0x559e5adb9eed in _start
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior decode.c:316:21
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10381
Issue ID: 10381
Summary: Logformat config is broken
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
After ITS#10140, logformat config parsing and emitting is broken. Some formats
don't emit in cn=config, some abort. On Windows, log prefix is corrupted.
Patch is being tested.
--
You are receiving this mail because:
You are on the CC list for the issue.