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=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=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.
https://bugs.openldap.org/show_bug.cgi?id=9596
Issue ID: 9596
Summary: Python test suite
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
The bash test suite is extremely limited, hard to write for and slow. We can't
lose it as it is also portable, but something should be introduced for
developers/CI on more modern systems and increase coverage.
A Python 3 seed for one is in development in MR!347.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9398
Issue ID: 9398
Summary: Stale accesslog cookie due to unclean shutdown
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If slapd terminates uncleanly, a checkpoint will be lost on the accesslog db.
Depending on the syncprov overlay checkpoint settings (usually no checkpointing
is enabled on the accesslog db) this can cause the system to refuse engage in
replication at startup.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9256
Bug ID: 9256
Summary: The ACLs required for SASL binding are not fully
documented
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: kop(a)karlpinc.com
Target Milestone: ---
Created attachment 727
--> https://bugs.openldap.org/attachment.cgi?id=727&action=edit
Patch massaging the SASL binding requirement docs
While some ACL requirements for SASL binding are documented, some are not.
E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is
not documented. Other requirements can be reasoned out based on the existing
documentation, but this can be very difficult when unfamiliar with all the
moving parts and the places they are documented. E.g. knowing that
(objectClass=*) is the default filter, and that there's _always_ _some_ filter,
and connecting this with ACLs required to do search-based SASL mapping.
The attached patch brings all the SASL binding requirements together in one
place in the docs and makes everything explicit. The word "SASL" is included,
for those searching for that keyword.
I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software
(and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=10086
Issue ID: 10086
Summary: test059 does not set up valid cn=config replication
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
For cn=config replication to be valid, the entryUUIDs must match throughout the
config database. However, this is not the case when test059 executes. The
entryUUID for 'dn: cn=config' differs between the two.
Example:
quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID:
cfcon.d/cn\=config.ldif
entryUUID: aea058c4-bf6e-103d-9e18-4582986e9372
quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID:
db.1.a/cn\=config\,cn\=consumer.ldif
entryUUID: ae9bd858-bf6e-103d-871e-5daccf782d22
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9786
Issue ID: 9786
Summary: liblber: missing export of ber_pvt_wsa_err2string
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: tobias.junghans(a)veyon.io
Target Milestone: ---
When building (cross-compiling) OpenLDAP via GCC/mingw-w64, an undefined
reference to ber_pvt_wsa_err2string() is reported when libldap.dll is linked.
This can be fixed easily by adding ber_pvt_wsa_err2string() to
libraries/liblber/lber.map
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9816
Issue ID: 9816
Summary: slapcat cordeumps during mdb subtree dump with -s
Product: OpenLDAP
Version: 2.5.11
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: khoffmann(a)united-internet.de
Target Milestone: ---
Created attachment 887
--> https://bugs.openldap.org/attachment.cgi?id=887&action=edit
gdb backtrace of slapcat run
When trying to use slapcat in combination with -b and -s in order to create a
LDIF backup of a mdb subtree, slapd crashes with a coredump (please see the
attached snippet with gdb output from a reproduced test tree). The problem was
reporducible with different mdb databases / suffixes and only appears with
option -s.
The same dump with -H 'ldap:///ou=users,o=company,c=de??sub?' instead of -s
ou=users,o=company,c=de works perfectly fine, as long as the "attrs part" is
empty in the ldap-uri. Also using slapcat with -b only (for a full database
dump) works fine as well.
I'm aware of the fact that -s option is marked as DEPRECATED - I'm not sure if
you are going to fix this bug or if you rather take the change to remove the
option completely from future major versions.
Please let me also know if it's expected behaviour that the -H option doesn't
work whenever the attribute part isn't empty and if I should contribute to a
documentation update for this edge case.
Best regards,
Kris
--
You are receiving this mail because:
You are on the CC list for the issue.