Conflicts:
	NEWS
	configure.ac

Reviewed-by: Thiago Macieira <thiago@kde.org>
[build system adjusted to compile it even if we don't have GLib -smcv]

Using a va_list more than once is non-portable: it happens to work
under the ABI of (for instance) x86 Linux, but not x86-64 Linux.

This led to _dbus_printf_string_upper_bound() crashing if it should
have returned exactly 1024 bytes. Many system services can be induced
to process a caller-controlled string in ways that
end up using _dbus_printf_string_upper_bound(), so this is a denial of
service.
Reviewed-by: Thiago Macieira <thiago@kde.org>

dbus-daemon will crash due to invalid service file which key/value
starts before section. In that situation, new_line() will try to access
invalid address.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=60853Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Also update README to not mention libxml2.

This commit does several more strictly check for dbus-send as its usage
suggested.

* now --address is an invalid option but --address=, this just like the
  others, say --reply-timeout=, --dest=, --type=
* --print-reply= only take an optional argument "=literal"
* --print-reply= will cause error with missing MSEC and invalid MSEC
  will cause invalid value error
* --dest= will cause error with missing a NAME and also call
  dbus_validate_bus_name to verify the NAME
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65424Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65424Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

From git history, enable_x11 was used to track have_x11, but it's
useless now.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65443Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

[The libxml code path has been broken for at least 2.5 years, and Expat
is tiny, so there seems no point in supporting both. -smcv]

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=20253Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

dbus-daemon will crash due to invalid service file which key/value
starts before section. In that situation, new_line() will try to access
invalid address.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=60853Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65415Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

It turns out that if you don't second-guess the system by catching
SIGINT, the right things happen: it's received by every program in the
foreground process group, including dbus-run-session and dbus-daemon.
Neither of those catch SIGINT (unlike dbus-launch) so they'll exit
gracefully without the wrapper script needing to do anything special.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39196Reviewed-by: Colin Walters <walters@verbum.org>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39196Reviewed-by: Colin Walters <walters@verbum.org>
[reformatted from roff to Docbook -smcv]

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39196Reviewed-by: Colin Walters <walters@verbum.org>

Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

When dbus-daemon receives a request to activate a systemd service before
systemd has connected to it, it enqueues a fake request to "activate"
systemd itself (as a way to get a BusPendingActivationEntry to track the
process of waiting for systemd). When systemd later joins the bus,
dbus-daemon sends the actual activation message; any future activation
messages are sent directly to systemd.

In the "pending" code path, the activation messages are currently
dispatched as though they had been sent by the same process that sent
the original activation request, which is wrong: the bus security
policy probably doesn't allow that process to talk to systemd directly.
They should be dispatched as though they had been sent by the
dbus-daemon itself (connection == NULL), the same as in the non-pending
code path.

In the worst case, if the attempt to activate systemd timed out, the
dbus-daemon would crash with a (fatal) warning, because in this special
case, activation_message is a signal with no serial number, whereas the
code to send an error reply is expecting a method call with a serial
number.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=50199Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Tested-by: Ma Yu <yu.ma@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

When dbus-daemon receives a request to activate a systemd service before
systemd has connected to it, it enqueues a fake request to "activate"
systemd itself (as a way to get a BusPendingActivationEntry to track the
process of waiting for systemd). When systemd later joins the bus,
dbus-daemon sends the actual activation message; any future activation
messages are sent directly to systemd.

In the "pending" code path, the activation messages are currently
dispatched as though they had been sent by the same process that sent
the original activation request, which is wrong: the bus security
policy probably doesn't allow that process to talk to systemd directly.
They should be dispatched as though they had been sent by the
dbus-daemon itself (connection == NULL), the same as in the non-pending
code path.

In the worst case, if the attempt to activate systemd timed out, the
dbus-daemon would crash with a (fatal) warning, because in this special
case, activation_message is a signal with no serial number, whereas the
code to send an error reply is expecting a method call with a serial
number.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=50199Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Tested-by: Ma Yu <yu.ma@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>

On Unix, we use a pthreads mutex, which can be allocated and
initialized in global memory.

On Windows, we use a CRITICAL_SECTION, together with a call to
InitializeCriticalSection() from the constructor of a global static
C++ object (thanks to Ralf Habacker for suggesting this approach).

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>

From the department of "if it isn't tested, it doesn't work". I tried
compiling dbus without an assortment of optional features:

    in_builddir ~/build/dbus/legacy ${MR_REPO}/configure \
        --enable-developer --enable-maintainer-mode --enable-tests \
        dbus_cv_sync_sub_and_fetch=no \
        --disable-selinux \
        --disable-inotify \
        --disable-dnotify \
        --disable-epoll \
        --disable-kqueue \
        --disable-launchd \
        --disable-systemd \
        --disable-libaudit \
        --without-valgrind \
        --disable-x11-autolaunch \
        && ...

and it resulted in -Wunused warnings.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=64362Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>

This reverses the relationship between these two functions.
Previously, dbus_threads_init() wouldn't allocate dbus_cond_event_tls
on Windows, call check_monotonic_clock on Unix, or call
_dbus_check_setuid on Unix.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>

On pthreads platforms, POSIX guarantees that we can "allocate" mutexes
as library-global variables, without involving malloc. This means we
don't need to error-check their allocation - if the dynamic linker
succeeds, then we have enough memory for all our globals - which is an
important step towards being thread-safe by default. In particular,
making atomic operations never rely on DBusMutex means that we are free
to implement parts of DBusMutex in terms of DBusAtomic, if it would help.

We do not currently support any non-Windows platform that does not have
pthreads. This is unlikely to change.

On Windows, we already used real atomic operations; we can just
delete the unused global variable.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>

This patch also take care of different install directories on unix like os.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59733Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Conflicts:
	NEWS
	configure.ac