https://bugs.openldap.org/show_bug.cgi?id=9732
Issue ID: 9732
Summary: OpenLDAP TLS ciphersuite and groups limit issue
Product: OpenLDAP
Version: 2.4.54
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: narayananballem(a)gmail.com
Target Milestone: ---
Hi Team,
Hope you can help with this issue.
I am trying to disable SSLV3 on OpenLDAP servers we are using OpenLDAP as a
proxy with upstream Active directory servers. we are using CA certs on this
openssl we would like to disable SSLV3
I added the below entry slapd.conf but when I tried to start slapd it's failing
to start
TLSCipherSuite HIGH:MEDIUM:!SSLv2:!SSLV3
errors as below
slapd[19899]: main: TLS init def ctx failed: -1
slapd[19899]: slapd stopped.
slapd[19899]: connections_destroy: nothing to destroy.
debug logs restart as below
TLS: could not set cipher list HIGH:MEDIUM:!SSLv2:!SSLV3.
617c64c1 main: TLS init def ctx failed: -1
617c64c1 slapd stopped.
Also, did anybody notice this issue?
I am facing the issue with a group display we have several users in group while
looking for groups in getent group we are seeing a few groups not sure if there
is any limit on group filed in Database
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9002
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=8226
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8226
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=9002
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9715
Issue ID: 9715
Summary: Consolidate code for loglevel/logfile for better
shared usage between slapd and lloadd
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
In a future release, consolidate logging code, loglevel bits to be better
shared between slapd and stand-alone lloadd.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9723
Issue ID: 9723
Summary: C_EOF not reset in mdb_cursor_get with MDB_FIRST_DUP
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: stephan.j.bircher(a)gmail.com
Target Milestone: ---
I'm on the master branch of lmdb.
Steps to reproduce
// search for an non-existent key
rc = mdb_cursor_get(cursor, &key, &val, MDB_SET_RANGE);
if (rc == MDB_NOTFOUND) {
// C_EOF is not set on the cursor flags
// go to the last.
// C_EOF remains set which is ok
mdb_cursor_get(mdbCursor, &key, &val, MDB_LAST);
// go to the first dup of the last
// C_EOF remains set which is NOT OK
mdb_cursor_get(mdbCursor, &key, &val, MDB_FIRST_DUP);
// return MDB_NOTFOUND in any case whether there are duplicates or not
// because C_EOF was not cleared
mdb_cursor_get(mdbCursor, &key, &val, MDB_NEXT_NODUP);
}
Possible fix:
case MDB_FIRST_DUP:
mfunc = mdb_cursor_first;
mmove:
if (data == NULL || !(mc->mc_flags & C_INITIALIZED)) {
rc = EINVAL;
break;
}
if (mc->mc_xcursor == NULL) {
rc = MDB_INCOMPATIBLE;
break;
}
if (mc->mc_ki[mc->mc_top] >= NUMKEYS(mc->mc_pg[mc->mc_top])) {
mc->mc_ki[mc->mc_top] = NUMKEYS(mc->mc_pg[mc->mc_top]);
rc = MDB_NOTFOUND;
break;
}
{
MDB_node *leaf = NODEPTR(mc->mc_pg[mc->mc_top],
mc->mc_ki[mc->mc_top]);
if (!F_ISSET(leaf->mn_flags, F_DUPDATA)) {
MDB_GET_KEY(leaf, key);
rc = mdb_node_read(mc, leaf, data);
break;
}
}
if (!(mc->mc_xcursor->mx_cursor.mc_flags & C_INITIALIZED)) {
rc = EINVAL;
break;
}
rc = mfunc(&mc->mc_xcursor->mx_cursor, data, NULL);
// FIX: clear C_EOF
if (rc == MDB_SUCCESS && mc->mc_flags & C_EOF && mfunc ==
mdb_cursor_first) {
mc->mc_flags ^= C_EOF;
}
break;
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9492
Issue ID: 9492
Summary: Add local logging capa
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: mhardin(a)symas.com
Target Milestone: ---
Enhancement request: Add capability to slapd to log to a local file with log
rotation features. Log format should not change from syslog-generated log
style.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9641
Issue ID: 9641
Summary: accesslog when logging failed operations interferes
with deltasync
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: replication
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Take delta-MPR setup and accesslog configured with logsuccess off. We encounter
a conflicting write (one that fails to apply in the DB) and fall back to plain
syncrepl. Since we are configured to log that write, syncprov sees it (it is a
failure, so doesn't match filter, which should contain reqResult=0) and sends a
LDAP_SYNC_NEW_COOKIE with that CSN to our delta-consumers. While we apply this
write locally in the fallback session, the consumers will skip what they see as
a duplicate and lose the change.
My understanding is that for failed operations, we should ignore the CSN we
received with the operation and instead set up a new one (with our own sid).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7215
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|TEST |FIXED
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9700
Issue ID: 9700
Summary: Need to determine new library ABI versioning starting
point
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
With the change in how OpenLDAP client libraries are versioned vs prior
releases, we need to determine a useful starting point for the current ABI
prior to release.
Since current libldap is versioned as libldap.so.2, we may want to start with
ol_api_current=2
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9157
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|TEST |FIXED
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.