Post-release version bump

Signed-off-by: Simon McVittie <smcv@collabora.com>

Prepare v1.12.24

Signed-off-by: Simon McVittie <smcv@collabora.com>

Update NEWS

Signed-off-by: Simon McVittie <smcv@collabora.com>

test: Parse a message with a byteswapped Unix fd index

Reproduces: https://gitlab.freedesktop.org/dbus/dbus/-/issues/417
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit bef693f442d854505e7013fd31efe41747d7493c)
[backport to 1.14.x: discard Meson build system updates]
(cherry picked from commit 71dd3ad20cf8aca3310fa8d533801fb1d8bdaf1a)
[backport to 1.12.x: resolve conflicts in Autotools build system]

test: Add infrastructure to parse valid raw message blobs

Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 7a2c13d21be702c7b5b7288fb82a60adc5bd7378)
[backport to 1.14.x: discard Meson build system updates]
(cherry picked from commit 7a8f3c2af94063e4994a9780d00d700aa0ea8aef)
[backport to 1.12.x: resolve conflicts in build system; adjust signature
of test function for absence of 39ef65d0 in this branch]

dbus-marshal-byteswap: Byte-swap Unix fd indexes if needed

When a D-Bus message includes attached file descriptors, the body of the
message contains unsigned 32-bit indexes pointing into an out-of-band
array of file descriptors. Some D-Bus APIs like GLib's GDBus refer to
these indexes as "handles" for the associated fds (not to be confused
with a Windows HANDLE, which is a kernel object).

The assertion message removed by this commit is arguably correct up to
a point: fd-passing is only reasonable on a local machine, and no known
operating system allows processes of differing endianness even on a
multi-endian ARM or PowerPC CPU, so it makes little sense for the sender
to specify a byte-order that differs from the byte-order of the recipient.

However, this doesn't account for the fact that a malicious sender
doesn't have to restrict itself to only doing things that make sense.
On a system with untrusted local users, a message sender could crash
the system dbus-daemon (a denial of service) by sending a message in
the opposite endianness that contains handles to file descriptors.

Before this commit, if assertions are enabled, attempting to byteswap
a fd index would cleanly crash the message recipient with an assertion
failure. If assertions are disabled, attempting to byteswap a fd index
would silently do nothing without advancing the pointer p, causing the
message's type and the pointer into its contents to go out of sync, which
can result in a subsequent crash (the crash demonstrated by fuzzing was
a use-after-free, but other failure modes might be possible).

In principle we could resolve this by rejecting wrong-endianness messages
from a local sender, but it's actually simpler and less code to treat
wrong-endianness messages as valid and byteswap them.

Thanks: Evgeny Vereshchagin
Fixes: ba7daa60 "unix-fd: add basic marshalling code for unix fds"
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/417
Resolves: CVE-2022-42012
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 236f16e444e88a984cf12b09225e0f8efa6c5b44)
(cherry picked from commit 3fb065b0752db1e298e4ada52cf4adc414f5e946)

test: Add targeted tests for dbus/dbus#413, dbus/dbus#418

Unlike the message-internals test, these do not rely on extra debug
instrumentation in libdbus, and so can be used for "as-installed"
testing. (However, they do require GLib.)

Reproduces: https://gitlab.freedesktop.org/dbus/dbus/-/issues/413
Reproduces: https://gitlab.freedesktop.org/dbus/dbus/-/issues/418
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 3ef342410a1cefe3d0bfaf46279c6517f4b44a26)
(cherry picked from commit 6b88e768d887470573bc746bf9f22a24f2c00dbf)
[backport to 1.12.x: resolve conflicts; call _dbus_header_delete_field
directly because _dbus_message_remove_unknown_fields didn't yet exist
in this branch]

dbus_message_demarshal: Set error if we can't allocate the loader

Backported from 1.13.0. Previously this was fixed in the dbus-1.14 branch
but unfixed in the dbus-1.12 branch, but we need it fixed in dbus-1.12
if we want the additional test coverage for dbus#413 to pass.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit ecbcffae19ff1b811fc7d0d602458c0f00dd6771)

test: Export G_TEST_BUILDDIR, G_TEST_SRCDIR

These environment variables are used by GLib's g_test_build_filename()
and related convenience functions, which make it easier for unit tests
to find data files in a way that works for both build-time tests and
"as-installed" tests. During "as-installed" testing, both variables
will normally be unset, and GLib uses the directory containing the
executable. In most cases that results in the right thing happening, and
this will also be true for dbus, since we install the test executables
in ${libexecdir}/installed-tests, helper executables in the same place,
and test data in ${libexecdir}/installed-tests/data.

Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 37e01259435a28b11a087867ea199cd09f0a5cff)
[backport to 1.14.x: discard Meson build system updates]
(cherry picked from commit bbf5ef008a629af62f817771adee6ae4adcf3bcd)
[backport to 1.12.x: resolve conflicts in CMake build system]

test/data: Add messages that reproduce dbus/dbus#413, dbus/dbus#418

In debug builds with "embedded tests" enabled, these will automatically
be used as input for the message-internals test.

Some of the messages themselves are output from a fuzzer, others are
simplifications to include only one reason for lack of validity per
message.

I've included an annotated hex-dump for each message here, but the dbus
test suite doesn't currently know how to convert hex to binary, so I've
also committed the corresponding binary. See the comment at the top of
each hex-dump for how to create the binary version (which requires the
xxd tool shipped with vim).

It would be nice for the dbus test suite to be able to convert the
annotated hex-dump to binary, either at build-time with a Python script
or at runtime by loading the text file and decoding the hex, but I don't
want to block on that for dbus/dbus#413 and dbus/dbus#418.

Reproduces: https://gitlab.freedesktop.org/dbus/dbus/-/issues/413
Reproduces: https://gitlab.freedesktop.org/dbus/dbus/-/issues/418
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit d633016f7340f83142f19f4bcac08c57e1f2fd2f)
[backport to 1.14.x: discard Meson build system updates]
(cherry picked from commit c0bfcc097896fb57a96f55818fc5fe97db679cbf)
[backport to 1.12.x: resolve conflicts vs. Autotools before 09076dfe]

dbus-marshal-validate: Validate length of arrays of fixed-length items

This fast-path previously did not check that the array was made up
of an integer number of items. This could lead to assertion failures
and out-of-bounds accesses during subsequent message processing (which
assumes that the message has already been validated), particularly after
the addition of _dbus_header_remove_unknown_fields(), which makes it
more likely that dbus-daemon will apply non-trivial edits to messages.

Thanks: Evgeny Vereshchagin
Fixes: e61f13cf "Bug 18064 - more efficient validation for fixed-size type arrays"
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/413
Resolves: CVE-2022-42011
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 079bbf16186e87fb0157adf8951f19864bc2ed69)
(cherry picked from commit b9e6a7523085a2cfceaffca7ba1ab4251f12a984)

test-syntax: Exercise correctly- and incorrectly-nested structs, dicts

Reproduces: https://gitlab.freedesktop.org/dbus/dbus/-/issues/418
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 67800ac5febc9f15d6c4f113c758797472842ff3)
(cherry picked from commit fd73d1ef1ba6ba4e55c07f5e65300bf40a94917f)

dbus-marshal-validate: Check brackets in signature nest correctly

In debug builds with assertions enabled, a signature with incorrectly
nested `()` and `{}`, for example `a{i(u}` or `(a{ii)}`, could result
in an assertion failure.

In production builds without assertions enabled, a signature with
incorrectly nested `()` and `{}` could potentially result in a crash
or incorrect message parsing, although we do not have a concrete example
of either of these failure modes.

Thanks: Evgeny Vereshchagin
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/418
Resolves: CVE-2022-42010
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 9d07424e9011e3bbe535e83043d335f3093d2916)
(cherry picked from commit 3e53a785dee8d1432156188a2c4260e4cbc78c4d)

NEWS: Describe the behaviour change resulting from fixing dbus#416

Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 1aa0d897c25b22ed9f23ce5bb164b4076687bf9c)

dbus-server-socket: Make unix:tmpdir equivalent to unix:dir

On Linux, there are two classes of AF_UNIX socket, which D-Bus refers
to as unix:path=... (portable to non-Linux systems) and unix:abstract=...
(not portable).

Back in 2003 when dbus gained support for abstract Unix sockets on Linux,
everyone thought they were better in every way than path-based Unix
sockets: if a DBusServer crashes or is terminated abnormally, there's
no detritus left in the filesystem. What's not to like? As a result,
since commit a70b042f (2003-06-04), when a DBusServer listens on a
unix:tmpdir=... address on Linux, the default is for the result to be
a unix:abstract=... address, with unix:path=... addresses only used on
non-Linux platforms.

However, the world has changed in the last 19 years, and namespace-based
Linux containers (which didn't exist in 2003) are now very popular. This
makes abstract sockets problematic.

Abstract sockets are tied to the network namespace, which is
all-or-nothing: if a container is to access the Internet without using
some sort of proxy or intermediary (like slirp4netns) then it needs to
share the network namespace with the host system, and that implies
sharing all abstract sockets with the host system. If the well-known
session bus is listening on an abstract socket, then it's a sandbox
escape route for any sandboxed or containerized app running under the
same uid. Conversely, if a container is *not* sharing the network
namespace with the host system, then it cannot access a session bus that
is listening on an abstract socket without using some sort of proxy
(like xdg-dbus-proxy), even if it isn't intended to impose a security
boundary and giving it direct access to the session bus would have been
more desirable.

Path-based sockets do not have this problem because they exist in the
filesystem (part of the "everything is a file" Unix philosophy),
allowing mount namespaces and bind-mounts to be used to share or
unshare them selectively.

On systems with `systemd --user` where dbus has been configured with
`--enable-user-session`, in general the session bus will already be
using a path-based socket for the "user bus", disregarding the listening
address specified in /usr/share/dbus-1/session.conf. The default in many
recent Linux distributions is either to use dbus-daemon in this way, or
to use dbus-broker, a reimplementation of the message bus service which
has similar "user bus" behaviour.

However, the <listen> address in session.conf is used when dbus-launch(1)
or dbus-run-session(1) is used to start a session bus, either manually,
via autolaunching, or via system integration glue in operating systems
that are not using `systemd --user`. This will occur particularly often
in operating systems that boot using a non-systemd init system.

Making unix:tmpdir=/tmp equivalent to unix:dir=/tmp ensures that the
well-known session bus listens on a path-based socket, allowing container
and sandboxing frameworks to mediate access to it in the same way they
would for the user bus. The D-Bus Specification already allows (but does
not require) this behaviour, because it is the only thing that was
implementable on non-Linux systems such as *BSD.

This change has the potential to cause regressions. If a container
framework enters a chroot or unshares the mount namespace but does not
unshare the network namespace, and is relying on the ability for a
process inside a container to access the session bus outside the
container via its abstract socket, then that assumption will be broken
by this change. Some use cases of schroot(1) are likely to suffer from
this. However, container frameworks with that assumption would already
have found that it does not hold when using the user bus, and it is
necessary to break that assumption if we want it to be possible to apply
application-level sandboxing in a secure way.

Another potential regression from this change is that if a dbus-daemon
is terminated abnormally, it will leave a socket in /tmp. Distributors
of operating systems where heavy use of dbus-launch(1) is expected might
wish to run dbus-cleanup-sockets(1) periodically.

This partially reverts commit a70b042f.

Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/416
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit f01382ae310c7d63790c07ed280f575d91ea57b8)
[backport to 1.14.x: adjust to absence of d98c98d1 in this branch]
(cherry picked from commit b5a09fb11c05b3b1922e99d18720f586fc91cd0b)

Update NEWS for 1.12.x

Signed-off-by: Simon McVittie <smcv@collabora.com>

build: Opt out from using mingw-w64's replacement printf(), etc.

The Windows code in dbus is careful to use Windows-specific equivalents
of the Standard C features that are not implemented by msvcrt.dll, so
we don't need to substitute a Standard C printf implementation.

This avoids compiler warnings/errors when gcc expects us to be using
Microsoft printf syntax (`ms_printf` attribute), but newer versions of
mingw-w64 expect us to be using GNU or Standard C printf syntax
(`gnu_printf` attribute) as a result of `__USE_MINGW_ANSI_STDIO` being
enabled by default if not otherwise specified.

Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/380
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit daf362ee61170727be0ca5dec1cf39435485ad0c)

bus/dir-watch: Do not crash with > 128 dirs

Without this running, dbus-daemon with long XDG_DATA_DIRS
will crash on out-of-bounds write:

$ XDG_DATA_DIRS=$(seq  -f "/foo/%g" -s ':' 129) dbus-daemon --session
*** stack smashing detected ***: terminated

(cherry picked from commit b551b3e9737958216a1a9d359150a4110a9d0549)
Backported-from: dbus!302
(cherry picked from commit 9e8fe0718c1abf93e92fcf98c3fe962fc524bfa8)

Merge branch '1.12-ci' into 'dbus-1.12'

Fix CI for 1.12.x

See merge request dbus/dbus!342

CI: Use Debian 11 'bullseye' for most builds

dbus 1.12.x was included in both Debian 10 'buster', which is now EOL,
and Debian 11 'bullseye', which continues to be supported. I need this
branch to work on Debian 11 for security and bugfix backports, but I'm
no longer supporting Debian 10.

Leave one build variant, the "legacy" build, on Debian 10 to check that
we can still build there, to be nice to the Debian LTS subproject.

Also continue to use Debian 10 for mingw builds, since dbus#380 has
not been fixed in this branch (which is now the security-fix-only
old-stable branch, so the fix will not be backported).

Signed-off-by: Simon McVittie <smcv@collabora.com>

CI: Don't pin msys2 packages to a specific version at all

Similar to dbus/dbus!286, but more so: just use the package names,
ignoring their version numbers completely.

pcre2 is not strictly needed at the moment, but it'll be a dependency
for GLib >= 2.73.x (older versions used pcre). For a bit of
future-proofing, download both pcre and pcre2.

Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 8aa34131dd3665df1c0d6a2c92600e04593d09c0)

tools/ci-install.sh: clean up the previously used installation prefix and the downloaded mingw packages

This is necessary to have a clean initial state when running the script
locally.

Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
(cherry picked from commit 067733d4b0e7c9c03ee25cb85eecb80980f01f68)

tools/ci-install.sh: Use partially qualified versions with mingw package names

Fixes dbus/dbus#388

Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
(cherry picked from commit 85f5f0503855fed561c010b4676f8aeb3a77424f)

tools/ci-install.sh: on debian|ubuntu reduce the need for mingw package name changes

Instead of having to specify an exact version that needs to be adjusted
with each repository update, it is now possible to specify package names
without version or partially qualified versions, which reduces the
frequency of necessary adjustments.

This is achieved by searching for the package names in a previously
downloaded list of available packages.

Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
(cherry picked from commit 7e9d3708b1fea32c71ede2087083eeb179fc164b)

Post-release version bump

Signed-off-by: Simon McVittie <smcv@collabora.com>

Prepare v1.12.22

Signed-off-by: Simon McVittie <smcv@collabora.com>

doc: Uninstall *.svg generated by Doxygen

Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 8afc535770f2b82467311c6f6e486f5b88a93941)

NEWS: Update

Signed-off-by: Simon McVittie <smcv@collabora.com>

Merge branch '1.12-backports' into 'dbus-1.12'

[1.12.x] Backport various fixes to dbus-1.12

See merge request dbus/dbus!258

bus/signal: fix compilation when only -Dembedded-tests

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
(cherry picked from commit a58d46b78957de03119dd54ab1a8346ff850abdb)

sysdeps-unix: Diagnose failure to open /proc/self/oom_score_adj

Previously, we silently ignored this, but now that we're more careful
about the contexts in which we try to reset the OOM score and whether
we log failures as a warning, we can let the dbus-daemon-launch-helper
show a message if it can't write there.

Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 226f24144a4db4898a1f5958293d200b975baee0)

spawn-unix: Don't log an error if unable to reset Linux OOM score

We cannot safely log between fork() and exec() because it isn't an
async-signal-safe operation (in particular it might allocate memory).

We also don't want to treat a failure here as a real problem, because
it might legitimately not work: in a system dbus-daemon that has dropped
privileges from root, the pseudo-file representing this process parameter
remains owned by root and cannot be altered by the unprivileged user.

For the main use-case for this operation, the system dbus-daemon, we
have another opportunity to do this in the dbus-daemon-launch-helper
(see the previous commit).

Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 7ee72a27957be5d3436beaa02ccd01b9ce042962)

dbus-daemon-launch-helper: Reset Linux OOM score adjustment here

Previously, we were relying on the system bus being able to reset
its OOM score adjustment after it forks, but before it execs the
dbus-daemon-launch-helper. However, it can't actually do that (leading
to dbus#378), because the system bus typically starts as root, uses its
root privileges to adjust resource limits, and then drops privileges
to the `@DBUS_USER@`, typically `dbus` or `messagebus`. This leaves the
pseudo-files in /proc for its process parameters owned by root, and the
`@DBUS_USER@` is not allowed to open them for writing.

The dbus-daemon-launch-helper is setuid root, so it can certainly
alter its OOM score adjustment before exec'ing the actual activated
service. We need to do this before dropping privileges, because after
dropping privileges we would be unable to write to this process
parameter.

This is a non-async-signal-safe context, so we can safely log errors
here, unlike the fork-and-exec code paths.

Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/378
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 2efb462466d628d47d7f80c5a8e864a62b6154cc)

spawn-unix: On Linux, don't try to increase OOM-killer protection

The oom_score_adj parameter is a signed integer, with increasingly
positive values being more likely to be killed by the OOM-killer,
and increasingly negative values being less likely.

Previously, we assumed that oom_score_adj would be negative or zero,
and reset it to zero, which does not require privileges because it
meant we're voluntarily giving up our OOM-killer protection.
In particular, bus/dbus.service.in has OOMScoreAdjust=-900, which
we don't want system services to inherit.

However, systemd >= 250 has started putting a positive oom_score_adj
on user processes, to make it more likely that the OOM killer will kill
a user process rather than a system process. Changing from a positive
oom_score_adj to zero is increasing protection from the OOM-killer,
which only a privileged process is allowed to do, resulting in warnings
whenever we carry out traditional (non-systemd) service activation
on the session bus.

To avoid this, do the equivalent of:

    if (oom_score_adj < 0)
        oom_score_adj = 0;

which is always allowed.

Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/374
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit c42bb64457c3b31e561ad9885c618e051af1171a)

sysdeps-unix: Factor out _dbus_reset_oom_score_adj

Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit f3ffe9a873708c679df88b9fc12b6b831539cf8a)

spawn-unix: Correct indentation

Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 715a1a920d06f5c7ee66629691ff892d7870ff04)

tests: Ensure session bus has started before integration test

The session dbus-daemon won't necessarily be run immediately on login
if we are using systemd socket activation for it, and the transient
services directory $XDG_RUNTIME_DIR/dbus-1/services isn't created until
it's actually run. Ping the dbus-daemon to make sure it's available.

Signed-off-by: Simon McVittie <smcv@debian.org>
Bug-Debian: https://bugs.debian.org/1005889
(cherry picked from commit 47a4bdfaf8f31ebb20f2d0b549109cb946b08440)

Merge branch '1.12-ci' into 'dbus-1.12'

[1.12.x] CI: Partially catch up with 1.13.x

See merge request dbus/dbus!259

CI: Remove EOL versions of Debian and Ubuntu

Debian 9 'stretch' is EOL, and Ubuntu 16.04 is EOL unless you enter into
a special subscription with Canonical. This puts them outside our
informal security-support policy, and realistically, anyone sufficiently
change-averse to be following these distributions is not going to be
backporting a current version of dbus.

Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 69c610f6f084a3f68994043d2bf11f18016e8052)

.gitlab-ci.yml: Use x86_64 build chain to cross build 64bit executables

This error was discovered when working with the merge request
dbus/dbus!158.

(cherry picked from commit 74717a9c0cec5879f405b4e439aded80c2b6dc7f)

Remove `build:` prefix from jobs to make labels more visible in pipeline page

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 d2bab84329e7ca34011d64cafd6af5d1399789ec)

CI: Don't build on Debian 8 'jessie'

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 3ce28815e9bd07bc8ebf2e36cc5e75815f535c19)

CI: Build on Debian 10 'buster' by default

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 73cfcb95c6f122b741a56450036c865807a4d64f)

CI: Use Python 3

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>

CI: Use https to download MSYS packages

Signed-off-by: Simon McVittie <smcv@collabora.com>

CI: Install ci-certificates

We need this to be able to download MSYS packages now.

Signed-off-by: Simon McVittie <smcv@collabora.com>

CI: Fix unpack of documentation tarball

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>

ci: bump msys2 deps, fix broken links

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
(cherry picked from commit c5385dfd60ac7ca64c6742d33dd82688769805fe)

tools/ci-install.sh: Use package=() style for local package list to avoid '\' notation

(cherry picked from commit 6412ccdf67b8440916a6a0f8b9b1741aa988192f)

On CI use common install prefix named 'dep_prefix' for installing local packages

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 9c5734fe9019dd40a5c7491206aa820f430035d6)

tools/ci-build.sh: Clean up directories from possible previous builds

Otherwise, ci-build.sh cannot be executed on a local system if there
are previous runs.

(cherry picked from commit e82d5fe48623337fd5a69317e27b7a8ce195398a)

tools/ci-install.sh: merge multiple calls to apt-get

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 478484f13c9f291d1c8bc1b3e3672f382d4d03d9)
[backport for 1.12.x: This branch still needed python-dbus, python-gi]
Signed-off-by: Simon McVittie <smcv@collabora.com>

Move installing packages into tools/ci-install.sh

In tools/ci-build.sh the cross compile setup has to be moved further up
to match the correct subdirectory.

(cherry picked from commit 1e3d82d85e9a59ccabb329c8f2401207edd419be)

CI: Do the CMake native debug build from an Autotools `make dist`

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 1063bba06b4e4236350c426d3edf37f069728465)
[backport for 1.12.x: in 1.12.x, `make dist` produces .tar.gz]

CI: Install yelp-tools, for yelp-build, in recent distros

Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 78efbb6c0d3bb052f7381f35a9d1d2c4bacc8c0c)

CI: Make adduser properly non-interactive

Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 52fcc82379cc24196407828eb042b7f2f10b3f52)

CI: Don't install weak dependencies (Recommends)

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 cb6abc63919d6f84f634aee94d20c53d2759c382)

ci: Teach ci-install.sh to install wine on Debian 9 'stretch'

Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=108177
Acked-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit 408b222a9fc61327cd7be385b6705f30f0c38802)

ci-build: Update required MSYS packages

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 053238254ec1cd145208d19c808678b61a6a6566)

CI: Add ci_variant parameter

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>

Belatedly bump version number to 1.12.21 for development

Signed-off-by: Simon McVittie <smcv@collabora.com>

Update NEWS

Signed-off-by: Simon McVittie <smcv@collabora.com>

internals: Use Standard C offsetof macro if available

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 a24cf746e2a8191070efd1300a15d37284aaf2fa)

disable fork-malloc-exec for non-glibc-systems

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 3fab06d68f5940cde89fb9c7e647bdc48bc7b253)

doc: Don't include TODO list in API documentation

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 ce8d7759a2afeb961d10be96724af2630de362e5)

docs: generate reproducible ids

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 43e0188dbf6506f64150f3a9b2392e315b1bbdaf)

dbus-launch: Replace slashes in DISPLAY if present

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: #8
Resolves: #311
(cherry picked from commit 3545d0f4de0194ced1fde6935fd7d1326dd9e832)

sysdeps: Don't raise RLIMIT_NOFILE beyond OPEN_MAX on macOS

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 691946dabcdd3e97787655d977a4da33fe56d433)

Reference CVE-2020-35512 in NEWS

Signed-off-by: Simon McVittie <smcv@collabora.com>

Merge branch 'cherry-pick-f0e526bc' into 'dbus-1.12'

tests: On Unix, include <netinet/in.h> for IPPROTO_TCP

See merge request dbus/dbus!168

tests: On Unix, include <netinet/in.h> for IPPROTO_TCP

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 f0e526bca8a5e47246c97199f5c388b0bd00d9f3)

v1.12.20

Signed-off-by: Simon McVittie <smcv@collabora.com>

Update NEWS

Signed-off-by: Simon McVittie <smcv@collabora.com>

userdb: Reference-count DBusUserInfo, DBusGroupInfo

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 2b7948ef907669e844b52c4fa2268d6e3162a70c)

userdb: Make lookups return a const pointer

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 6ee66ff7bcc91803111d950512f02651e664f74f)

Solaris and derivatives do not adjust cmsg_len on MSG_CTRUNC

(cherry picked from commit b96ef23e406baa08648339a53b0161fc80de7ce4)

Start 1.12.20 development

Signed-off-by: Simon McVittie <smcv@collabora.com>

Prepare 1.12.18

Signed-off-by: Simon McVittie <smcv@collabora.com>

fdpass test: Assert that we don't leak file descriptors

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>

sysdeps-unix: On MSG_CTRUNC, close the fds we did receive

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

Update NEWS

Signed-off-by: Simon McVittie <smcv@collabora.com>

dbus-daemon test: Don't test fd limits if in an unprivileged container

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

Update NEWS

doxygen: fix example for dbus_message_append_args

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>

Update NEWS

cmake: Add X11 include path for tools

Fixes compilation issues for case when X11 is not in a standard location

doc: replace dbus-send's --address with --peer and --bus

See merge request dbus/dbus!115

(cherry picked from commit fd41caa3664d480605628f08c217581bc42fa3e7)

Update NEWS

Merge branch 'cherry-pick-b034b83b' into 'dbus-1.12'

[1.12] bus: Don't explicitly clear BusConnections.monitors

See merge request dbus/dbus!142

bus: Don't explicitly clear BusConnections.monitors

Each connection that is an active monitor holds a pointer to its own
link in this list, via BusConnectionData.link_in_monitors. We can't
validly free the list while these pointers exist: that would be a
use-after-free, when each connection gets disconnected and tries to
remove itself from the list.

Instead, let each connection remove itself from the list, then assert
that the list has become empty.

Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: https://gitlab.freedesktop.org/dbus/dbus/issues/291

(cherry picked from commit b034b83b59efffd4cc819ad42d0cd078d91d53df)

Merge branch 'cherry-pick-bf71a58e' into 'dbus-1.12'

doc: Fix environment variable name in dbus-daemon(1)

See merge request dbus/dbus!141

doc: Fix environment variable name in dbus-daemon(1)

Spotted by Mubin. This documentation relates to the code in
add_bus_environment() in bus/activation.c.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #275

(cherry picked from commit bf71a58e4ab496c1726209aaad94a1abe670a01f)

Start 1.12.18 development

Signed-off-by: Simon McVittie <smcv@collabora.com>

Prepare version 1.12.16

Signed-off-by: Simon McVittie <smcv@collabora.com>

test: Add basic test coverage for DBUS_COOKIE_SHA1

We don't actually complete successful authentication, because that
would require us to generate a cookie and compute the correct SHA1,
which is difficult to do in a deterministic authentication script.
However, we do assert that dbus#269 (CVE-2019-12749) has been fixed.

Signed-off-by: Simon McVittie <smcv@collabora.com>

auth: Reject DBUS_COOKIE_SHA1 for users other than the server owner

The DBUS_COOKIE_SHA1 authentication mechanism aims to prove ownership
of a shared home directory by having the server write a secret "cookie"
into a .dbus-keyrings subdirectory of the desired identity's home
directory with 0700 permissions, and having the client prove that it can
read the cookie. This never actually worked for non-malicious clients in
the case where server uid != client uid (unless the server and client
both have privileges, such as Linux CAP_DAC_OVERRIDE or traditional
Unix uid 0) because an unprivileged server would fail to write out the
cookie, and an unprivileged client would be unable to read the resulting
file owned by the server.

Additionally, since dbus 1.7.10 we have checked that ~/.dbus-keyrings
is owned by the uid of the server (a side-effect of a check added to
harden our use of XDG_RUNTIME_DIR), further ruling out successful use
by a non-malicious client with a uid differing from the server's.

Joe Vennix of Apple Information Security discovered that the
implementation of DBUS_COOKIE_SHA1 was susceptible to a symbolic link
attack: a malicious client with write access to its own home directory
could manipulate a ~/.dbus-keyrings symlink to cause the DBusServer to
read and write in unintended locations. In the worst case this could
result in the DBusServer reusing a cookie that is known to the
malicious client, and treating that cookie as evidence that a subsequent
client connection came from an attacker-chosen uid, allowing
authentication bypass.

This is mitigated by the fact that by default, the well-known system
dbus-daemon (since 2003) and the well-known session dbus-daemon (in
stable releases since dbus 1.10.0 in 2015) only accept the EXTERNAL
authentication mechanism, and as a result will reject DBUS_COOKIE_SHA1
at an early stage, before manipulating cookies. As a result, this
vulnerability only applies to:

* system or session dbus-daemons with non-standard configuration
* third-party dbus-daemon invocations such as at-spi2-core (although
  in practice at-spi2-core also only accepts EXTERNAL by default)
* third-party uses of DBusServer such as the one in Upstart

Avoiding symlink attacks in a portable way is difficult, because APIs
like openat() and Linux /proc/self/fd are not universally available.
However, because DBUS_COOKIE_SHA1 already doesn't work in practice for
a non-matching uid, we can solve this vulnerability in an easier way
without regressions, by rejecting it early (before looking at
~/.dbus-keyrings) whenever the requested identity doesn't match the
identity of the process hosting the DBusServer.

Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: https://gitlab.freedesktop.org/dbus/dbus/issues/269
Closes: CVE-2019-12749

Start 1.12.16 development

Signed-off-by: Simon McVittie <smcv@collabora.com>

Release 1.12.14

Update NEWS

Signed-off-by: Simon McVittie <smcv@collabora.com>

bus: Try to raise soft fd limit to match hard limit

Linux systems have traditionally set the soft limit to 1024 and the hard
limit to 4096. Recent versions of systemd keep the soft fd limit at
1024 to avoid breaking programs that still use select(), but raise the
hard limit to 512*1024, while in recent Debian versions a complicated
interaction between components gives a soft limit of 1024 and a hard
limit of 1024*1024. If we can, we might as well elevate our soft limit
to match the hard limit, minimizing the chance that we will run out of
file descriptor slots.

Unlike the previous code to raise the hard and soft limits to at least
65536, we do this even if we don't have privileges: privileges are
unnecessary to raise the soft limit up to the hard limit.

If we *do* have privileges, we also continue to raise the hard and soft
limits to at least 65536 if they weren't already that high, making
it harder to carry out a denial of service attack on the system bus on
systems that use the traditional limit (CVE-2014-7824).

As was previously the case on the system bus, we'll drop the limits back
to our initial limits before we execute a subprocess for traditional
(non-systemd) activation, if enabled.

systemd activation doesn't involve us starting subprocesses at all,
so in both cases activated services will still inherit the same limits
they did previously.

This change also fixes a bug when the hard limit is very large but
the soft limit is not, for example seen as a regression when upgrading
to systemd >= 240 (Debian #928877). In such environments, dbus-daemon
would previously have changed its fd limit to 64K soft/64K hard. Because
this hard limit is less than its original hard limit, it was unable to
restore its original hard limit as intended when carrying out traditional
activation, leaving activated subprocesses with unintended limits (while
logging a warning).

Reviewed-by: Lennart Poettering <lennart@poettering.net>
[smcv: Correct a comment based on Lennart's review, reword commit message]
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 7eacbfece70f16bb54d0f3ac51f87ae398759ef5)
[smcv: Mention that this also fixes Debian #928877]