https://bugs.openldap.org/show_bug.cgi?id=10455
Issue ID: 10455
Summary: Allow handling of empty group in
memberof_saveMember_cb()
Product: OpenLDAP
Version: 2.6.12
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: roger.j.meier(a)gmx.ch
Target Milestone: ---
Created attachment 1117
--> https://bugs.openldap.org/attachment.cgi?id=1117&action=edit
Protect e_attrs with a NULL pointer test instead of an assert() to allow empty
groups
In slapd/overlays/memberof.c, the callback
memberof_saveMember_cb()
uses two assert statements for the sr_entry and its e_attrs pointer in
sequence. This makes the service abort on an empty group. If the use of
rs->sr_entry->e_attrs is just protected by a test of the e_attrs pointer, the
code does not abort and allows empty groups.
Please consider to add this patch to the official source.
It was now several month in production and did not lead to unexpected results.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10269
Issue ID: 10269
Summary: slap-constraint: Refactor to use a sorted array
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: quanah(a)openldap.org
Target Milestone: ---
As noted in the comments for slapo-constraint:
/*
* Linked list of attribute constraints which we should enforce.
* This is probably a sub optimal structure - some form of sorted
* array would be better if the number of attributes constrained is
* likely to be much bigger than 4 or 5. We stick with a list for
* 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=9284
Issue ID: 9284
Summary: Need man page for vc contrib overlay
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The verified credentials overlay in contrib is missing a man page describing
its purpose
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10277
Issue ID: 10277
Summary: How to deal with desync between cn=config and
back-ldif DNs
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: ---
If someone deletes a cn=config entry offline (or through bugs in cn=config,
they exist, will file as I isolate), the X-ORDERED RDNs will not be contiguous.
cn=config papers over this internally at a cost of never being able to modify
the entries affected.
Right now the only remedy is slapcat+slapadd of the whole config DB, is that
the best we can do? When we detect this (doesn't always happen), should we fix
the on-disk copy on startup?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9782
Issue ID: 9782
Summary: regression test its8752 failure
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: ---
If a contextCSN update (new cookie) goes from server A through server B to
server C, server C will use that CSN to update entryCSN as well (which neither
A nor B did). This fails the initial replication check.
The issue has likely existed since deltasync was made possible, a version of
this is confirmed at least in 2.4.60 onwards to current master. In principle,
it is related to concerns raised in ITS#9580.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10217
Issue ID: 10217
Summary: autoca should support more key types
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: enhancement
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Currently autoca only creates certificates using RSA keypairs. It should at
least have an option to use Elliptic Curve keypairs. It probably also needs
options to specify other signature algorithms other than the default of SHA256.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10257
Issue ID: 10257
Summary: Documentation assessment
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Created attachment 1031
--> https://bugs.openldap.org/attachment.cgi?id=1031&action=edit
Admin guide assessment
Last month I commissioned a tech writer to review the current 2.6 Admin Guide
to see what needs to be worked on before the 2.7 release. I'm attaching the
report here so we can reference it. Should have distributed it sooner but Life
got in the way.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10403
Issue ID: 10403
Summary: Add a configuration directive that uses the OpenSSL
CONF API to allow openldap config files to set any
configuration supported by that API, and to get new
OpenSSL configuration capabilities through that API
with no changes in openldap.
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: stephen.wall(a)redcom.com
Target Milestone: ---
Created attachment 1090
--> https://bugs.openldap.org/attachment.cgi?id=1090&action=edit
Add a configuration directive that uses the OpenSSL CONF API to allow openldap
config files to set any configuration supported by that API, and to get new
OpenSSL configuration capabilities through th
I am submitting a patch to create a new directive for OpenLDAP config files
that uses the OpenSSL SSL_CONF API to allow configuration of any aspect of
OpenSSL that the API supports without adding specific directives to OpenLDAP
for them. When OpenSSL extends that API, all versions of OpenLDAP with thie
patch will also support those extensions with no additional code.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10311
Issue ID: 10311
Summary: Work with IETF LDAP working group to update password
hashing mechanism RFC
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: ---
Work with the IETF ldap working group to update the RFC to make the suggested
hashing mechanism be what is currently "best practice" rather than a specific
hashing mechanism.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9272
Issue ID: 9272
Summary: Invalid search results for subordinate/glued database
Product: OpenLDAP
Version: 2.4.47
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: grapvar(a)gmail.com
Target Milestone: ---
Here is a trivial test case. Look at the following bunch of glued
dit's/databases, declared in this order:
| suffix ou=a,ou=1,ou=T # subordinate; contains only one (top-level) entry
| suffix ou=2,ou=T # subordinate; contains only one (top-level) entry
| suffix ou=b,ou=1,ou=T # subordinate; contains only one (top-level) entry
| suffix ou=T # master database, has two entries, top-level
| ` ou=1 # ... and this child entry
let's query the united database:
| $ ldapsearch -b ou=1,ou=T -s sub '' nx
| dn: ou=1,ou=T
| dn: ou=a,ou=1,ou=T
| dn: ou=b,ou=1,ou=T
Nice! But wait, what if ...
| $ ldapsearch -b ou=1,ou=T -s sub -E\!pr=2/noprompt '' nx
| dn: ou=1,ou=T
| dn: ou=a,ou=1,ou=T
|
| # pagedresults: cookie=//////////8=
... BANG! ...
| Server is unwilling to perform (53)
The problem is the glue_op_search(), which has issues
* different parts of code make different assumptions about data structures
* different parts of code track state inconsistently
* code that looks like a highly probably dead code
I mean that likely possible to build another bug-triggering test cases, and
glue_op_search() needs not just a fix of the bug above, but intense cleaning
and structuring.
--
You are receiving this mail because:
You are on the CC list for the issue.