https://bugs.openldap.org/show_bug.cgi?id=9221
Bug ID: 9221
Summary: Move all replication consumer code into its own
overlay
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
(In relation to a discussion about slapo-chain)
<hyc> anyway, the nicer ting to fix would be in 2.5, push all of the repl
consumer code into its own overlay
<hyc> in that case, updateref would be processed wherever the overlay was
configured
<hyc> so no longer tied to the frontend
<hyc> it would also make it more feasible to have multiple different consumer
configs in a single DB, each with their own provider URL (and thus their own
updateref)
<hyc> I would think we can get rid of the update ref directive entirely, just
point all writes to that consumer's provider.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9218
Bug ID: 9218
Summary: Revist entry_release handling in slapo-pache,
slapo-translucent
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
From a past discussion with hyc on 2.5 items:
[13:57] <hyc> there's a nagging problem though, pcache's entry_release function
needs to distinguish between its backend actually freeing the entry, or being a
no-op
[13:57] <hyc> so it can decide whether to return success or continue
[13:58] <hyc> the patch to translucent sidesteps the question, by avoiding
other overlays
[13:58] <hyc> but we need to revisit this in 2.5
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9217
Bug ID: 9217
Summary: Audit all schema definitions to have official
non-experimental OIDs where possible
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
From a past discussion with hyc on 2.5 requirements:
[09:27] <hyc> we also need to audit all of these schema defs
[09:27] <hyc> we're supposed to have official, non-experimental OIDs for
released schema
[09:28] <hyc> accesslog is still using 666, experimental arc
[09:29] <hyc> I think this means we should polish up the logschema draft,
Informational status, and publish it again as final
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9216
Bug ID: 9216
Summary: Port autoca to gnutls
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
For 2.5, support building and running the autoca overlay with GnuTLS.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9278
Issue ID: 9278
Summary: liblmdb: robust mutexes should not be unmapped
Product: LMDB
Version: unspecified
Hardware: All
OS: FreeBSD
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: delphij(a)freebsd.org
Target Milestone: ---
Created attachment 736
--> https://bugs.openldap.org/attachment.cgi?id=736&action=edit
A possible workaround
We recently noticed that lmdb would have the memory region containing the
robust mutex unmapped on mdb_env_close0():
munmap((void *)env->me_txns,
(env->me_maxreaders-1)*sizeof(MDB_reader)+sizeof(MDB_txninfo));
Note that if this is the last unmap for a robust mutex, the FreeBSD
implementation would garbage-collect the mutex, making it no longer visible to
other processes. As the result, a second instance of the attached test.c (from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244493 with minor changes)
would trigger the assertion at mdb_txn_begin() because the acquisition of the
mutex would return 22 (EINVAL), because the mutex appeared to be a robust
mutex, but was invalid.
The attached lmdb.diff is a possible workaround for this (it would skip
unmapping when setting up the robust mutex for the first time).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9471
Issue ID: 9471
Summary: Add RBAC overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its RBAC overlay to core
The slapo-rbac overlay is an implementation of the ANSI INCITS 359 Role-Based
Access Control (RBAC) Core.
When instantiated, it intercepts, decodes and enforces specific RBAC policies
per the Apache Fortress RBAC data formats.
The overlay provides a set of extended operations.
They include session create/delete, checkAccess, addActiveRole, dropActiveRole
and sessionRoles.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9472
Issue ID: 9472
Summary: Add datamorph overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its datamorph overlay to core
The datamorph overlay to slapd allows attributes with a few predefined values
to be saved more space-efficiently as well as signed or unsigned integer
attributes.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9473
Issue ID: 9473
Summary: Add variant overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its variant overlay to OpenLDAP core
The variant overlay to slapd allows attributes/values to be shared between
several entries. In some ways this is similar to slapo-collect with the
exception that the source and target attributes can be different.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9436
Issue ID: 9436
Summary: OpenSSL 3.0: libldap uses depreciated functions
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
OpenLDAP master fails to build against OpenSSL 3.0 alpha when "no-deprecated"
is specified.
Currently hitting these errors:
./.libs/libldap.so: undefined reference to `SSL_get_peer_certificate'
./.libs/libldap.so: undefined reference to `PEM_read_bio_DHparams'
./.libs/libldap.so: undefined reference to `ERR_get_error_line'
./.libs/libldap.so: undefined reference to `DH_free'
./.libs/libldap.so: undefined reference to `SSL_CTX_set_tmp_dh'
Notes:
SSL_get_peer_certificate is SSL_get1_peer_certificate in 3.0.0
SSL_CTX_set_tmp_dh should be replaced as follows:
# define SSL_CTX_set_tmp_dh(ctx,dh) \
SSL_CTX_ctrl(ctx,SSL_CTRL_SET_TMP_DH,0,(char *)(dh))
Have to dig deeper for:
PEM_read_bio_DHparams
ERR_get_error_line
DH_free
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9460
Issue ID: 9460
Summary: Drop support for OpenSSL older than 1.1.1
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
OpenSSL no longer supports the 1.0.2 series and specifically notes it should
not be used:
"All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of
support and should not be used."
Currently configure checks for 1.0.2 or higher.
OpenSSL 1.1.1 is supported through 11 Sep 2023.
--
You are receiving this mail because:
You are on the CC list for the issue.