https://bugs.openldap.org/show_bug.cgi?id=8884
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.7.1 |2.7.2
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10573
Issue ID: 10573
Summary: OpenLDAP 2.7.0 fails to build with MSVC when
preprocessing symbol version maps
Product: OpenLDAP
Version: 2.7.0
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: openldap-msvc-673e3a64ee4f43(a)emalupe.com
Target Milestone: ---
OpenLDAP 2.7.0 fails to build with MSVC while generating the liblber symbol
version map. The regression appears to have been introduced by commit
8651f98a08c37bea6ee9be78acececd52bac66a0 (ITS#9739).
The new rules in libraries/liblber/Makefile.in and
libraries/libldap/Makefile.in invoke:
$(CPP) -x c -o $@ $(LT_CPPFLAGS) $(srcdir)/$(SYMBOL_VERSION_SCRIPT).in
The -x c option is specific to GCC/Clang. When Autoconf's configured C
preprocessor is MSVC (cl -E), cl ignores -x and treats the following c as an
input filename:
cl : Command line warning D9002 : ignoring unknown option '-x'
c1: fatal error C1083: Cannot open source file: 'c': No such file or
directory
make[2]: *** [Makefile:301: lber.map] Error 2
This was reproduced with OpenLDAP 2.7.0 and Visual Studio 2026/MSVC 14.51 on
Windows. OpenLDAP 2.6.13 builds successfully with the same compiler setup
because it does not preprocess these map files.
The same non-portable invocation is present in both the liblber and libldap
map-generation rules and remains in the current OPENLDAP_REL_ENG_2_7 and master
branches.
Could the hard-coded compiler language option be removed or replaced with a
configure-detected, compiler-portable way to preprocess the .map.in files?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8375
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.7.1 |2.7.2
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10583
Issue ID: 10583
Summary: lloadd logging enhancements
Product: OpenLDAP
Version: 2.7.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: enhancement
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: smckinney(a)symas.com
Target Milestone: ---
The logs do not contain the bind result or the identity of the caller which
complicates troubleshooting issues.
--
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
----------------------------------------------------------------------------
Target Milestone|2.7.1 |2.7.2
--
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.