F29 System Wide Change: Make dbus-broker the default DBus implementation
by Jan Kurik
= Proposed System Wide Change: Make dbus-broker the default DBus
implementation =
https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplemen...
Owner(s):
* David Herrmann <dh dot herrmann at gmail dot com>
* Tom Gundersen <teg at jklm dot no>
Enable dbus-broker.service to use dbus-broker as system and session
message bus backend.
== Detailed description ==
The dbus-broker project is an implementation of a message bus as
defined by the D-Bus specification. Its aim is to provide high
performance and reliability, while keeping compatibility to the D-Bus
reference implementation. It is exclusively written for linux systems,
and makes use of many modern features provided by recent linux kernel
releases.
The main focus points of dbus-broker are reliability, scalability and
security. The dbus-broker project tries to improve on these points
over dbus-daemon, and thus provide a better alternative. And in-depth
analysis can be found in the initial announcement of dbus-broker. An
excerpt:
* Accounting: dbus-broker maintains per-user accounting, including
inter-user quotas. This guarantees that no single user can cause
irregularly high memory consumption in the daemon. Unlike dbus-broker,
dbus-daemon accounts memory in a multi-tier system, based on plain
resource counters on users, connections, and other resources. The
multi-tier system suffers from resource-chaining-exhaustion, where
clients effectively circumvent the accounting by creating multiple
connections/objects, which themselves grant them each a new set of
quotas. The single-tier accounting scheme of dbus-broker avoids this,
while at the same time adding inter-user quotas to prevent misuse even
across clients.
* Reliability: While D-Bus is used on reliable transports, dbus-daemon
might still silently drop messages and given circumstances. This is
the only possible solution dbus-daemon has, given several of its
runtime guarantees. The dbus-broker project changed the architecture
of the bus daemon to a degree, that it can provide many guarantees,
including that no message will be silently, or unexpectedly, dropped.
* Scalability: The message bus broker is a crucial infrastructure on
modern linux system, which is a hot-path for almost all IPC going on.
Hence, the broker should perform fast and be scalable to its users.
dbus-daemon has several **global** data-structures that affect the
overall scalability of independent message transactions. dbus-broker
does not employ any global data-structures (unless required by the
spec), as such any message transaction is only affected by the data
provided by the involved peers. Moreover, even for spec-defined global
behavior, dbus-broker avoids global data-structures, unless clients
actually make use of these obscure features. In several other cases,
dbus-daemon scales O(n) time looking up message targets and related
data. dbus-broker runs all these in O(log(n)) time.
* Linux-specific: The dbus-broker project was explicitly designed for
linux system, making use of many linux-specific APIs and behavior.
This allows mitigation of several possible DoS attacks.
== Scope ==
* Proposal owners:
** Fix regressions.
** Enable dbus-broker.service in system and user-global context of
systemd (via systemd presets).
** Pull in dbus-broker package from dbus package.
* Other developers:
** Watch for regressions
* Release engineering: #7262 https://pagure.io/releng/issues/7262
* List of deliverables:
N/A
* Policies and guidelines:
No changes needed.
* Trademark approval:
No changes needed.
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 1 month
F29 Self Contained Change: OpenLDAP: Drop MozNSS Compatibility Layer
by Jan Kurik
= Proposed Self Contained Change: OpenLDAP: Drop MozNSS Compatibility Layer =
https://fedoraproject.org/wiki/Changes/OpenLDAPdropMozNSSCompatibilityLayer
Owner(s):
* Matus Honek <mhonek at redhat dot com>
Since Fedora 28, OpenLDAP is compiled with OpenSSL instead of NSS and
includes MozNSS Compatiblity Layer (i.e. TLSMC) to assure backwards
compatiblity. After this change the TLSMC will be removed.
== Detailed description ==
This change drops support for NSS-like configuration style for TLS in
OpenLDAP. Only PEM files will be supported. This is the expected
follow-up to the Changes/OpenLDAPwithOpenSSL [1].
The change will be accomplished by dropping a downstream patch that
brings the feature and removing all the related statements from the
SPEC file, including --enable-moznss-compatiblity=yes configure
option.
[1] https://fedoraproject.org/wiki/Changes/OpenLDAPwithOpenSSL
== Scope ==
* Proposal owners:
Drop downstream patching as described in #Detailed Description
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
[https://pagure.io/releng/issue/7382 #7382]
** List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 1 month
Open Seats on the Fedora Packaging Committee
by James Antill
The Fedora Packaging Committee has some open seats and is accepting
submissions from interested candidates to serve on the FPC.
The FPC would like to thank Ralf Corsepius, Dominik 'Rathann'
Mierzejewski, and Thomas Spura for their service.
This position involves not only reviewing Packaging Guideline drafts
submitted to the FPC for consideration, but also helping rewrite drafts
to resolve issues in a more acceptable fashion. Additionally, the FPC
reviews UID/GID soft static assignment.
Currently the FPC meets on IRC weekly, on alternate
Wednesdays/Thursdays based around 12:00 EST, for approximately an
hour.
However that is likely to change back to a single day/time slot, and
the time would depend on when is good for all the members (East Coast
US and German TZs, at least).
FPC members serve for as long as they are willing, there are currently
no term limits. All decisions are voted on using a +1 (for), 0
(abstain), and -1 (against) mechanism, and all decisions must be
approved by a majority (+5). FPC Meetings do not happen if quorum (5)
is not present. Candidates who are interested should provide the
following details to the FPC for consideration, by emailing it directly
to me (james(a)fedoraproject.org).
The FPC will consider all candidates, but strongly prefers candidates
who have extensive experience packaging in Fedora. We will accept
applications for the next two weeks (deadline Wednesday, 2018-03-14).
Name:
FAS Account:
Provenpackager? (Yes/No):
Main area of packaging interest/expertise:
Reason(s) for wanting to join the FPC:
Thanks in advance,
~James
6 years, 1 month
