The length if the displayed jobs is limited on the gitlab CI pipeline page
and is occupied partly be the prefix.
Cherry-picked from dbus/dbus/!192
(cherry picked from commit d2bab84329)
Debian 8 'jessie' has reached EOL for mainstream security support,
which puts it outside our usual distribution/OS support policy.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 3ce28815e9)
Previously, we built on Debian 9 'stretch' by default, and on
Debian 10 'buster' only on request. Let's reverse that so that we get
more modern toolchains, before Debian 9 'stretch' reaches EOL.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 73cfcb95c6)
The dbus-1.12 branch needed Python, which the master branch no longer
does, but we can at least use a modern Python.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In dbus 1.12.x, this was a tar.gz archive, not a tar.xz archive.
Fixes: 8d34987e "CI: Exercise maintainer-only documentation build"
Signed-off-by: Simon McVittie <smcv@collabora.com>
With this commit a new variable 'ci_local_packages' has been introduced
to have a choice for using development packages from a local installation
or from the distribution.
(cherry picked from commit 9c5734fe90)
This required a reorganization of the steps that had been carried out.
The new order is:
1. install packages with apt-get
2. create user for build if required
3. fetch and unpack tar balls
4. create messagebus user
(cherry picked from commit 478484f13c)
[backport for 1.12.x: This branch still needed python-dbus, python-gi]
Signed-off-by: Simon McVittie <smcv@collabora.com>
We officially release dbus in the form of Autotools `make dist` tarballs,
but people who have downloaded those tarballs should be able to choose
the CMake build system. Our CI should assert that they can.
(The Autotools debug build already does a `make distcheck`, which
asserts that tarball releases can be used for an Autotools build.)
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: dbus#255
(cherry picked from commit 1063bba06b)
[backport for 1.12.x: in 1.12.x, `make dist` produces .tar.gz]
In particular this avoids installing the TeX toolchain.
However, this also means we don't install dbus, which broke some tests
in minimal containers where dbus wasn't already installed, because the
messagebus user wouldn't have been created. Make sure that user exists,
using the same adduser call as the Debian dbus package.
CMake really wants to find a C++ compiler (even though we only use C++
when compiling for Windows), so explicitly install the default
version of the GNU C++ compiler, g++.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit cb6abc6391)
The older versions we were previously building against are no longer
available on mirrors.
Based on changes proposed in !189 by Arnout Engelen, and the package
list gathered by Ralf Habacker in #318.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/318
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 053238254e)
Originally part of commit 23e1f044 "Install qhelpgenerator for native
production build on buster". Later CI fixes rely on having this
available.
Signed-off-by: Simon McVittie <smcv@collabora.com>
clang 13 fails to compile our current implementation with:
.../dbus/dbus-message.c:2070:3: error: variable length array folded to constant array as an extension [-Werror,-Wgnu-folding-constant]
_DBUS_STATIC_ASSERT (_DBUS_ALIGNOF (DBusMessageRealIter) <=
^
.../dbus/dbus-internals.h:460:25: note: expanded from macro '_DBUS_STATIC_ASSERT'
typedef struct { char _assertion[(expr) ? 1 : -1]; } \
This appears to be because the "traditional" definition of
offsetof(), which we're hard-coding here, does not qualify as a constant
expression under C rules due to its use of pointer casts.
Modern compilers like gcc and clang have a built-in implementation
of offsetof that *is* a constant expression.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit a24cf746e2)
Calling malloc() after fork is undefined behaviour if the process is
multi-threaded. locks held by a thread on fork() will never be released.
malloc() is usally protected by a lock and can therefore deadlock. glibc
is known not to deadlock in this case.
This commit does not rule out other problems on glibc-systems, but fixes an
issue on musl-libc-systems. Only restricting to async-signal safe functions
between fork() and exec() prevents undefined behaviour for sure. See
signal-safety(7).
(cherry picked from commit 3fab06d68f)
This is sorted non-deterministically, which is undesired for reproducible
builds, and is not really part of the API in any case.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit ce8d7759a2)
With this parameter, docbook will generate the same id's when generating the
same docs. This is helpful to get bit-by-bit 'reproducible' output, which
makes auditing the package easier.
(cherry picked from commit 43e0188dbf)
dbus-daemon fails to autolaunch with X11 on macOS 10.8+ because XQuartz
(the X11 package for macOS) provides a value for `$DISPLAY` that is
not expected by dbus, in that it contains `/` characters. This is
addressed by replacing the invalid path character `/` with `_`.
Resolves: #8Resolves: #311
(cherry picked from commit 3545d0f4de)
dbus-daemon fails to launch on macOS 10.5 and above because of a breaking
change in setrlimit, in which RLIM_INFINITY is no longer supported
for RLIMIT_NOFILE. Instead we must use OPEN_MAX.
Resolves: #309
(cherry picked from commit 691946dabc)
Otherwise, dbus doesn't compile on FreeBSD if the GLib-based tests
are enabled (which suggests that no FreeBSD user has run those tests
successfully).
We already include <netinet/in.h> in other places with no conditions
or checks other than "is Unix", so apparently it's portable enough that
specifically testing for its presence is not necessary. POSIX requires it
to exist.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit f0e526bca8)
Previously, the hash table indexed by uid (or gid) took ownership of the
single reference to the heap-allocated struct, and the hash table
indexed by username (or group name) had a borrowed pointer to the same
struct that exists in the other hash table.
However, this can break down if you have two or more distinct usernames
that share a numeric identifier. This is generally a bad idea, because
the user-space model in such situations does not match the kernel-space
reality, and in particular there is no effective kernel-level security
boundary between such users, but it is sometimes done anyway.
In this case, when the second username is looked up in the userdb, it
overwrites (replaces) the entry in the hash table that is indexed by
uid, freeing the DBusUserInfo. This results in both the key and the
value in the hash table that is indexed by username becoming dangling
pointers (use-after-free), leading to undefined behaviour, which is
certainly not what we want to see when doing access control.
An equivalent situation can occur with groups, in the rare case where
a numeric group ID has two names (although I have not heard of this
being done in practice).
Solve this by reference-counting the data structure. There are up to
three references in practice: one held temporarily while the lookup
function is populating and storing it, one held by the hash table that
is indexed by uid, and one held by the hash table that is indexed by
name.
Closes: dbus#305
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 2b7948ef90)
This makes it more obvious that the returned pointer points to a
struct owned by the userdb, which must not be freed or have its
contents modified, and is only valid to dereference until the next
modification to the userdb's underlying hash tables (which in practice
means until the lock is released, because after that we have no
guarantees about what might be going on in another thread).
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 6ee66ff7bc)
This version is for the dbus-1.12 branch, and doesn't rely on dbus!153
or dbus!120.
Reproduces: dbus#294
Reproduces: CVE-2020-12049
Reproduces: GHSL-2020-057
Signed-off-by: Simon McVittie <smcv@collabora.com>
MSG_CTRUNC indicates that we have received fewer fds that we should
have done because the buffer was too small, but we were treating it
as though it indicated that we received *no* fds. If we received any,
we still have to make sure we close them, otherwise they will be leaked.
On the system bus, if an attacker can induce us to leak fds in this
way, that's a local denial of service via resource exhaustion.
Reported-by: Kevin Backhouse, GitHub Security Lab
Fixes: dbus#294
Fixes: CVE-2020-12049
Fixes: GHSL-2020-057
In an unprivileged container, uid 0 doesn't have CAP_SYS_RESOURCE, so
we can't expect the dbus-daemon to be able to escalate its fd limit.
This can be reproduced using bubblewrap:
sudo bwrap \
--cap-drop CAP_SYS_RESOURCE \
--ro-bind / / \
--dev /dev \
env \
DBUS_TEST_DAEMON=.../bus/dbus-daemon \
DBUS_TEST_DATA=.../test/data \
.../test/test-dbus-daemon \
-p /fd-limit \
--verbose
Bug-Debian: https://bugs.debian.org/908092
Commit 724adb2f6 mangled the dbus_message_append_args() code example.
This fixes it by breaking the lines and aligning at the right places.
Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
