https://bugs.openldap.org/show_bug.cgi?id=10183
Issue ID: 10183
Summary: ldapadd jump option
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: enhancement
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Same as the jump option added for slapadd in ITS#4555. Should have been added
long ago.
--
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=10186
Issue ID: 10186
Summary: Overlay response callbacks should ignore op->o_abandon
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Overlays that need to perform other DB write operations in their response
callbacks usually create a new Operation by copying the existing *op. If the op
had its o_abandon flag set, then every op the overlay starts will be
immediately abandoned instead of executing. They should zero out the
op->o_abandon flag, because the fact that the response callback got invoked
means the original operation already completed. If the main op actually
observed the abandon request, the response callbacks wouldn't have gotten
triggered.
This in particular affects the memberof overlay, which must perform other
modifications after the main op completes. It also affects the contrib
autogroup overlay. It might be relevant for accesslog as well, but I haven't
looked at that yet.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10176
Issue ID: 10176
Summary: new atexit() call to atexit(ldap_exit_tls_destroy) in
2.5.17 crashes AIX application
Product: OpenLDAP
Version: 2.5.17
Hardware: Other
OS: Other
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: philip.miloslavsky(a)gmail.com
Target Milestone: ---
We have a long standing openldap application that's being ported from 2.4.58 to
2.5.17.
On ppc AIX (but not on linux for which we also build), when we exit the main
application we get a crash in exit() because it is trying to run the atexit
which LDAP regsitered, but ldap has already been unloaded and the unloading
caused that atexit function pointer to become zero.
So I tracked it to this line of code in ldap 2.5.17 that was not there in
2.4.58
libraries/libldap/tls2.c: atexit( ldap_exit_tls_destroy );
If I remove that line of code, my issue goes away.
So, now on to dlcose and atexit.
So we have a main kernel (irisdb), a C++ library (ldap.so) that we wrote that
calls ldap client libraries, and the 2 actual openldap libraries which ldap.so
is linked against.
During irisdb exit (the h command)
irisdb does call dlclose on ldap.so, which as a side effect results in the
unloading of the 2 official openldap libraries, but no one calls unatexit() (on
the 0x09001000a04947a8 below).
After the 3 libraries are unloaded, the atexit registration is still there but
its been replaced with zeroes. At what point in this process should we call
unatexit or some LDAP function and why does this sequence of events work right
on linux but not AIX?
[5] stop in ldap_unbind_s
(dbx) c
[1] stopped in unload_sharedlib at line 7793 in file
"/nethome/pmilosla/perforce/projects/OpenLDAP4/kernel/common/src/cdzf.c" ($t1)
7793 if (!libptr)
(dbx) where
unload_sharedlib(libptr = 0x0000000000000004), line 7793 in "cdzf.c"
UnloadZFETable(zfetabdescp = 0x0a00010000032790), line 7346 in "cdzf.c"
ResetZFETable(), line 7940 in "cdzf.c"
zfrundown(), line 10135 in "cdzf.c"
chsub2(), line 3480 in "dmisc2.c"
chalt(flag = 1), line 3222 in "dmisc2.c"
Chaltcmd(), line 3146 in "dmisc2.c"
(dbx) p zfetabdescp->fnameptr
"/home/gavlak/gavlakcre7424/bin/ldap.so"
(dbx) 0x09001000a04947a8/2x
0x09001000a04947a8: 0900 0000
(dbx) 0x09001000a04947a8/4x
0x09001000a04947a8: 0900 0000 0491 8ec0
(dbx) c
[3] stopped in dlclose at 0x90000000029da40 ($t1)
0x90000000029da40 (dlclose) 7c0802a6 mflr r0
(dbx) where
dlclose(0x4) at 0x90000000029da40
unload_sharedlib(libptr = 0x0000000000000004), line 7804 in "cdzf.c"
UnloadZFETable(zfetabdescp = 0x0a00010000032790), line 7346 in "cdzf.c"
ResetZFETable(), line 7940 in "cdzf.c"
zfrundown(), line 10135 in "cdzf.c"
chsub2(), line 3480 in "dmisc2.c"
chalt(flag = 1), line 3222 in "dmisc2.c"
Chaltcmd(), line 3146 in "dmisc2.c"
(dbx) p zfetabdescp->fnameptr
"/home/gavlak/gavlakcre7424/bin/ldap.so"
(dbx) c
[2] stopped in exit at 0x9000000002524a0 ($t1)
0x9000000002524a0 (exit) 7c0802a6 mflr r0
(dbx) 0x09001000a04947a8/4x
0x09001000a04947a8: 0000 0000 0000 0000
(dbx) c
Illegal instruction in . at 0x0 ($t1)
0x0000000000000000 00000000 Invalid opcode.
(dbx) where
.() at 0x0
exit(??) at 0x900000000252610
syshalt(a = 0), line 6925 in "emisc.c"
chalt(flag = 1), line 3227 in "dmisc2.c"
Chaltcmd(), line 3146 in "dmisc2.c"
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10170
Issue ID: 10170
Summary: accesslog breaks if internal ops done in startup
Product: OpenLDAP
Version: 2.5.17
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
If some other overlay performs some internal operations in its db_open handler,
before all DBs and overlays are fully initialized, and accesslog_response is
invoked, it may crash if its logDB hasn't been initialized yet.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10044
Issue ID: 10044
Summary: dynlist sometimes crashes when a search operation is
abandoned
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: ---
Playing with the DB provided in ITS#10041 on master, interrupting the
ldapsearch sometimes leads to a slapd crash. It's not 100% repeatable and the
debugger shows dynlist_search2resp touching memory freed by
dynlist_search_cleanup already, which doesn't make sense. Might be something
else is happening at the same time.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10165
Issue ID: 10165
Summary: back-meta fails to bind to target when proxying an
internal operation
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 the target is configured as follows:
idassert-bind bindmethod=sasl saslmech=EXTERNAL authz=proxyauthz flags=override
and an overlay issues an internal operation, back-meta attempts to open a new
connection to the target, but the bind fails, so the internal operation cannot
be executed.
The target server returns the following error (as logged by back-meta):
<unauthenticated bind (DN with no password) disallowed>
Example configuration of the target server:
authz-regexp gidNumber=.*\+uidNumber=.*,cn=peercred,cn=external,cn=auth
cn=config
logfile ./main.log
database config
database mdb
directory ./main
rootdn cn=config
suffix o=example.com
overlay accesslog
logdb cn=log
logops writes
logsuccess true
database mdb
suffix cn=log
directory ./log
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10173
Issue ID: 10173
Summary: Accesslog bootstrap doesn't populate minCSN internally
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: ---
When a new accesslog DB is being set up from zero but a main DB exists, the
correct minCSN is pushed into the auditContainer entry but li_mincsn et al are
not set up internally. 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=10211
Issue ID: 10211
Summary: uid or gid >= 2^31 can crash slapd when performing
peercred auth
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: nick(a)portercomputing.co.uk
Target Milestone: ---
Created attachment 1018
--> https://bugs.openldap.org/attachment.cgi?id=1018&action=edit
Patch to resolve issue
If a user with uid or gid >= 2^31 performs peercred authentication, slapd can
crash due to incorrect formatting of uid and gid when producing the authid
string.
uid and gid are unsigned int values, but are currently cast to int and printed
with %d. This results in values >= 2^31 being printed as negatives, which is
wrong, and for some values that will result in a string longer than the space
which has been allocated due to the addition of the leading '-'.
The issue can be reproduced by attempting a peercred auth from a user with uid
and gid 2649996510 - which will currently be printed as -1644970786.
Attached is a patch which rectifies this.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10206
Issue ID: 10206
Summary: smbk5pwd.c: implicit declaration of function
'kadm5_s_init_with_password_ctx'
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
smbk5pwd.c: In function ‘smbk5pwd_modules_init’:
smbk5pwd.c:917:23: warning: implicit declaration of function
‘kadm5_s_init_with_password_ctx’; did you mean ‘kadm5_init_with_password_ctx’?
[-Wimplicit-function-declaration]
917 | ret = kadm5_s_init_with_password_ctx( context,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| kadm5_init_with_password_ctx
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10177
Issue ID: 10177
Summary: back-perl build for clang15
Product: OpenLDAP
Version: 2.5.17
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
back-perl cannot be built with clang15 on RHEL9.
The following error occurs:
```
libtool: link: clang -shared -fPIC -DPIC .libs/init.o .libs/search.o
.libs/close.o .libs/config.o .libs/bind.o .libs/compare.o .libs/modify.o
.libs/add.o .libs/modrdn.o .libs/delete.o .libs/version.o -Wl,-rpath
-Wl,/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/libldap/.libs
-Wl,-rpath
-Wl,/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs
-Wl,-rpath -Wl,/usr/local/lib
-L/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs
-L/usr/local/lib -L/usr/lib64/perl5/CORE -lperl -lpthread -lresolv -ldl -lm
-lcrypt -lutil ../../../libraries/libldap/.libs/libldap.so
/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs/liblber.so
-lsasl2 -lssl -lcrypto ../../../libraries/liblber/.libs/liblber.so -g -O0
-Wl,--enable-new-dtags -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -Wl,-z
-Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -fstack-protector-strong -Wl,-soname
-Wl,back_perl-2.5.so.0 -o .libs/back_perl-2.5.so.0.1.12
.libs/init.o: file not recognized: file format not recognized
clang-15: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [Makefile:348: back_perl.la] Error 1
make: Leaving directory
'/home/hamano/tmp/openldap-2.5.17/build-clang15/servers/slapd/back-perl'
```
The cause is that the `-flto=auto` flag prevents the generation with ELF
format.
```
$ file servers/slapd/back-perl/.libs/init.o
servers/slapd/back-perl/.libs/init.o: LLVM IR bitcode
```
I'll open gitlab PR.
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
https://bugs.openldap.org/show_bug.cgi?id=10215
Issue ID: 10215
Summary: [QUESTION] FIPS Validated password hashing
Product: OpenLDAP
Version: 2.4.54
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 11tete11(a)gmail.com
Target Milestone: ---
Hi! we are in process of a certification, and we are using openldap of ubuntu
pro fips 20.04, that its the 2.4.54
At some point the auditor ask us, how the passwords are stored into ldap, and
we found this:
https://github.com/openldap/openldap/tree/master/contrib/slapd-modules/pass…
seems that that module do not use a FIPS validated library like "openssl" that
comes with ubuntu fips. and make it's own implementation of the sha512.
Is there any ldap module that uses the openssl library of the SO that in this
case its the openssl 1.1.1f to hash its passwords?, could be this
https://github.com/openldap/openldap/tree/master/contrib/slapd-modules/pass…
maybe if i'm understanding right?
thx!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10198
Issue ID: 10198
Summary: Crash in mdb_strerr on Windows
Product: LMDB
Version: unspecified
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: b.koch(a)beckhoff.com
Target Milestone: ---
The call to FormatMessageA in mdb_strerr crashes on Windows 10 for error code
112 (disk full).
Its "Arguments" parameter is an invalid pointer. The documentation says that
the parameter should be ignored because of FORMAT_MESSAGE_IGNORE_INSERTS but my
copy of Windows disagrees. Documentation for FormatMessageA:
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-form…
The error is (with addresses replaced by <...>):
Exception thrown at <RtlFormatMessageEx> (ntdll.dll) in
ConsoleApplication1.exe: 0xC0000005: Access violation reading location
<buf+8*1024>.
Trivial fix: Change the last parameter to NULL (in this call:
https://github.com/LMDB/lmdb/blob/8645e92b937794c06f0c66dfae64e425a085b6cd/…)
Bug 8361 is raising some additional issues in this code and it implies that the
va_list is somehow related to the padding hack (but I don't understand how that
is, to be honest), so I'm not sure whether the trivial fix would be fine.
Here is some code to reproduce the crash outside of liblmdb (tested with Visual
Studio 2022, x86 and x64, C++ console project):
#include <iostream>
#include <windows.h>
int main()
{
std::cout << "Hello World!\n";
char buf[1024];
FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL, 112, 0, buf, sizeof(buf), (va_list*)buf + 1024);
char* msg = buf;
std::cout << msg;
}
--
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.