https://bugs.openldap.org/show_bug.cgi?id=10235
Issue ID: 10235
Summary: Configure without --enable-nestgroup=no enables
feature
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: stacey.marshall(a)gmail.com
Target Milestone: ---
OpenLDAP 2.6.8 configured with --enable-overlays.
Some openldap commands output a Duplicate attributeType notice, for example
# /sbin/slapcat -b cn=config -H ldap:///???olcTLSCertificateKeyFile=\* | grep
olcTLSCertificateKeyFile
register_at: AttributeType "( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC
'Group that the entry belongs to' SYNTAX '1.3.6.1.4.1.1466.115.121.1.12'
EQUALITY distinguishedNameMatch USAGE dSAOperation NO-USER-MODIFICATION
X-ORIGIN 'iPlanet Delegated Administrator' )": Duplicate attributeType,
1.2.840.113556.1.2.102
olcTLSCertificateKeyFile: /etc/certs/localhost/host.key
Specifying configure option --enable-nestgroup=no prevents nestgroup feature
and the message from being displayed.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10231
Issue ID: 10231
Summary: slapadd segfault on non-configured backend
Product: OpenLDAP
Version: 2.6.8
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: ---
If the LDIF being loaded corresponds to a different backend than the one
specified (or the default backend, if none was specified), and the specified
backend's configuration is incomplete and lacks a suffix, slapadd will SEGV
when trying to print the error message about the LDIF not matching the
specified
backend, because it tries to print the suffix but the suffix is NULL.
E.g. using this setup:
###
mkdir dumb dumb/db
cat > dumb/slapd.conf <<EOF
include schema/core.schema
backend ldif
database ldif
directory dumb/db
EOF
slapd -Ta -f dumb/slapd.conf -l schema/inetorgperson.ldif
###
When fixed, the normal error message will be shown instead:
slapadd: line 1: database #1 ((null)) not configured to hold
"cn=inetorgperson,cn=schema,cn=config"; did you mean to use database #0
(cn=config)?
Closing DB...
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10230
Issue ID: 10230
Summary: memberof addcheck must ignore other overlays
Product: OpenLDAP
Version: 2.6.8
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: ---
The addcheck feature added in ITS#10167 does a search to see if a newly added
entry is already a member of any existing groups, and fixes its memberof
attribute appropriately if so.
The values written here should only be static values, but if the nestgroup
overlay was configured, dynamic values were also being included.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10227
Issue ID: 10227
Summary: Asyncmeta will not reset a connection if a bind
operation fails with LDAP_OTHER, leaving the
connection in invalid state
Product: OpenLDAP
Version: 2.6.8
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: ---
The issue is difficult to reproduce, it can happen under heavy traffic if the
target is configured to do a sasl bind with a custom saslmech. In any case,
currently asyncmeta only resets the connection of the error is
LDAP_UNAVAILABLE, which is incorrect.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10219
Issue ID: 10219
Summary: Modify of olcDisabled by removing and adding a value
invokes db_open twice
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: nivanova(a)symas.com
Target Milestone: ---
A database is enabled by default, and therefore a missing olcDisabled attribute
is equivalent to a value of FALSE. This means that currently a modify operation
that removes a olcDisabled value will invoke the db_open handler for that
database, even if in the same modify operation a value of TRUE is added.
A modify operation like this:
dn: olcDatabase={1}asyncmeta,cn=config
changetype: modify
delete: olcDisabled
olcDisabled: FALSE
-
add: olcDisabled
olcDisabled: TRUE
-
will call both db_open and db_close. This could be potentially harmful if the
backend type allocates memory on db_open like asyncmeta, for example. It is a
rare case, but it is best to fix it just in case.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10218
Issue ID: 10218
Summary: Disabling and re-enabling an asyncmeta database via
cn=config leaks memory
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: ---
To reproduce - run OpenLDAP with valgrind, and set the olcDisabled attribute of
an asyncmeta database to TRUE, then again to FALSE. The connection structures
of the database are subsequently shown as leaked.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9827
Issue ID: 9827
Summary: Feature request for module argon2.so to support
Argon2i, Argon2d, Argon2id
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: juergen.sprenger(a)swisscom.com
Target Milestone: ---
Hi,
This is a feature request.
I would like to be able to chooses between Argon2i, Argon2d and Argon2id in
slappasswd like in argon2 command:
# argon2
Usage: argon2 [-h] salt [-i|-d|-id] [-t iterations] [-m log2(memory in KiB) |
-k memory in KiB] [-p parallelism] [-l hash length] [-e|-r] [-v (10|13)]
Password is read from stdin
Parameters:
salt The salt to use, at least 8 characters
-i Use Argon2i (this is the default)
-d Use Argon2d instead of Argon2i
-id Use Argon2id instead of Argon2i
-t N Sets the number of iterations to N (default = 3)
-m N Sets the memory usage of 2^N KiB (default 12)
-k N Sets the memory usage of N KiB (default 4096)
-p N Sets parallelism to N threads (default 1)
-l N Sets hash output length to N bytes (default 32)
-e Output only encoded hash
-r Output only the raw bytes of the hash
-v (10|13) Argon2 version (defaults to the most recent version,
currently 13)
-h Print argon2 usage
Example:
/usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o
module-load="argon2.so i" -s secret
/usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o
module-load="argon2.so d" -s secret
/usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o
module-load="argon2.so id" -s secret
Best regards
Juergen Sprenger
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10224
Issue ID: 10224
Summary: tlso_session_pinning: return codes from EVP* calls are
not checked; can result in crashes or undefined
behavior in library
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: yaneurabeya(a)gmail.com
Target Milestone: ---
EVP* calls made in tlso_session_pinning on lines 1189-1191 [1] are not checked
when computing the digest which is eventually placed in `keyhash.bv_val` on
line [2].
Not checking the EVP* calls can result in undefined behavior, e.g., a library
crash with SIGBUS, SIGSEGV, etc, and/or incorrect results when analyzing
`keyhash.bv_val` later.
The calls should be checked to avoid this scenario.
Reported by Coverity.
1.
https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5…
2.
https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10223
Issue ID: 10223
Summary: tlso_ctx_cipherfree: does not check result of
SSL_CTX_set_ciphersuites; can fail with incomplete
input provided earlier on in the function
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: yaneurabeya(a)gmail.com
Target Milestone: ---
The code on line 366 [1] doesn't check the return value of
SSL_CTX_set_ciphersuites(..) before returning from the function, if there's
leftover data in the tls13_suites buffer, after processing tls13_suites looking
for TLS v1.3 compatible ciphers.
OpenSSL doesn't state what specific scenarios could result in a failure with
the function, but doing some code inspection [2] it appears that a failure
could occur if the value provided in the second parameter (`str` per the
manpage [3]) to SSL_CTX_set_ciphersuites(..) is either invalid or an internal
memory allocation error occurs.
While this isn't necessarily something that can be easily handled, it would be
prudent to either ignore the return code explicitly by casting the result to
(void) and clearing the error, or handling the OpenSSL error explicitly, using
the ERR_* family APIs.
This issue was reported by Coverity.
1.
https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5…
2.
https://github.com/openssl/openssl/blob/5bbdbce856c7ca132e039a24a3156184848…
3. https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_ciphersuites.html
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10222
Issue ID: 10222
Summary: mdb_dump page has outdated information about
user-defined comparison functions
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: tools
Assignee: bugs(a)openldap.org
Reporter: zach.vonler(a)sambanovasystems.com
Target Milestone: ---
Created attachment 1019
--> https://bugs.openldap.org/attachment.cgi?id=1019&action=edit
Patch to mdb_dump man page
The `mdb_dump` man page contains an outdated section warning that databases
created with user-defined comparison functions cannot be dumped and reloaded
without changes to the `mdb_load` program. The `-a` option that was added to
the `mdb_load` program in this commit
https://github.com/openldap/openldap/commit/7796aaebcd1b937233adab5b1f3d3a1…
made it possible to reload such databases, so this patch updates the `mdb_dump`
man page to reflect that.
--
You are receiving this mail because:
You are on the CC list for the issue.