NEWS for 1.6

NEWS for 1.6.x

Make the test for #53499 more obviously correct

Test: add a test case for escaping byte > 127

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

Fix: a non ascii byte will trigger BadAddress error

If a byte in DBusString *unescaped isn't a ascii byte, which will be
cast to char (signed char on most of platform), so that's the issue
unsigned char cast to signed char. e.g. "\303\266" is a valid unicode
character, if everything goes right, it will be escaped to "%c3%b6".
However, in fact, it escaped to "%<garbage-byte>3%<garbage-byte>6".

_dbus_string_append_byte_as_hex() take an int parameter, so negative
byte is valid, but cause get a negative index in array. So garbage value
will get. e.g. '\303' --> hexdigits[((signed byte)(-61)) >> 4] is
hexdigits[-4].

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=53499
Sgne-off-by: Chengwei Yang <chengwei.yang@intel.com>
[fixed whitespace -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

NEWS

Remove invoke of va_end before va_start

Signed-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=66300

NEWS for #65959

DBusString: fix may crash if try to free an uninitialized str

If the str will be freed hasn't been initialized by _dbus_string_init
correctly, _dbus_string_free may crash due to trying to free an
undefined memory.

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

Add release name for 1.6.12

Start 1.6.13

Prepare embargoed release for tomorrow

Add a test-case for CVE-2013-2168

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

CVE-2013-2168: _dbus_printf_string_upper_bound: copy the va_list for each use

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>

NEWS for 1.6.x

Fix dbus-daemon crash due to invalid service file

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=60853
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Fix build error: unused-result

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

When "activating" systemd, handle its special case better

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=50199
Signed-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>

development version

Prepare release 1.6.10

NEWS for 1.6

Accept non-characters when validating Unicode

Unicode Corrigendum #9 clarifies that the non-characters U+nFFFE
(for n in the range 0 to 0x10), U+nFFFF (for n in the same range),
and U+FDD0..U+FDEF are valid for interchange, and their presence
does not make a string ill-formed.

GLib 2.36 made the corresponding change in its definition of UTF-8
as used by g_utf8_validate() and similar functions.

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

Allow use of GLib 2.32 functionality, which we do conditionally

Don't warn for functions deprecated since GLib 2.26

Also warn if we inadvertently use a function introduced since then.

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59971
Reviewed-by: Colin Walters <walters@verbum.org>

NEWS for 1.6

Don't access random memory if data slot isn't allocated yet

If DBUS_DISABLE_ASSERTS was turned on, and a buggy program called
dbus_connection_get_data() with a slot number less than zero (eg,
before even allocating the data slot), random memory would be
accessed and a random value returned.  Anything less than zero
is not a valid slot number and should be rejected by libdbus.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=63127
Signed-off-by: Dan Williams <dcbw@redhat.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

NEWS for 1.6

If alloca.h is available it is required (e.g. on Solaris 10)

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

NEWS for 1.6

Create missing directories in cmake <build-root>/bus/session.d and <build-root>/bus/system.d

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

NEWS

Don't leak temporary fds pointing to /dev/null

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=56927
[commit message added -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Fix building with newer Valgrind

Newer valgrind (tried with 3.8.0) defines macros so that a terminating
semi-colon is required. This fixes usage to follow that convention.

[edited to remove comments that are no longer useful -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=55932
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

activation helper: when compiled for tests, do not reset system bus address

Otherwise, the tests try to connect to the real system bus, which will
often fail - particularly if you run the tests configured for the default
/usr/local (with no intention of installing the result), in which case
the tests would try to connect to /usr/local/var/run/dbus/system_bus_socket.

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

Post-release version bump

Release 1.6.8

Revert "hardening: Use __secure_getenv() in *addition* to _dbus_check_setuid()"

Follow to reverting a556443757b19fee67ef4441141246dd9cfed4f.
See https://bugs.freedesktop.org/show_bug.cgi?id=52202#c24

This reverts commit d7ffad72146c2329692e0cf32eb1ac1dbb4fb51c.

Revert "hardening: Use __secure_getenv if available"

It breaks gnome-keyring-daemon at least in some
configurations; see
https://bugs.freedesktop.org/show_bug.cgi?id=52202#c24

This reverts commit 1a556443757b19fee67ef4441141246dd9cfed4f.

Resume development

Release 1.6.6

activation-helper: Ensure DBUS_STARTER_ADDRESS is set correctly

The fix for CVE-2012-3524 filters out all environment variables if
libdbus is used from a setuid program, to prevent various spoofing
attacks.

Unfortunately, the activation helper is a setuid program linking
libdbus, and this creates a regression for launched programs using
DBUS_STARTER_ADDRESS, since it will no longer exist.

Fix this by hardcoding the starter address to the default system bus
address.

Signed-off-by: Geoffrey Thomas <gthomas@mokafive.com>
Signed-off-by: Colin Walters <walters@verbum.org>

hardening: Remove activation helper handling for DBUS_VERBOSE

It's not really useful.

See https://bugs.freedesktop.org/show_bug.cgi?id=52202#c17

hardening: Use __secure_getenv() in *addition* to _dbus_check_setuid()

This is a further security measure for the case of Linux/glibc
when we're linked into a binary that's using filesystem capabilities
or SELinux domain transitions (i.e. not plain old setuid).

In this case, _dbus_getenv () will return NULL because it will
use __secure_getenv(), which handles those via AT_SECURE.

https://bugs.freedesktop.org/show_bug.cgi?id=52202

hardening: Ensure _dbus_check_setuid() is initialized threadsafe manner

This is a highly theoretical concern, but we might as well.

https://bugs.freedesktop.org/show_bug.cgi?id=52202

hardening: Use __secure_getenv if available

This helps us in the case where we were executed via filesystem
capabilities or a SELinux domain transition, not necessarily a plain
old setuid binary.

https://bugs.freedesktop.org/show_bug.cgi?id=52202

CVE-2012-3524: Don't access environment variables or run dbus-launch when setuid

This matches a corresponding change in GLib.  See
glib/gutils.c:g_check_setuid().

Some programs attempt to use libdbus when setuid; notably the X.org
server is shipped in such a configuration. libdbus never had an
explicit policy about its use in setuid programs.

I'm not sure whether we should advertise such support.  However, given
that there are real-world programs that do this currently, we can make
them safer with not too much effort.

Better to fix a problem caused by an interaction between two
components in *both* places if possible.

How to determine whether or not we're running in a privilege-escalated
path is operating system specific.  Note that GTK+'s code to check
euid versus uid worked historically on Unix, more modern systems have
filesystem capabilities and SELinux domain transitions, neither of
which are captured by the uid comparison.

On Linux/glibc, the way this works is that the kernel sets an
AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
startup.  If found, then glibc sets a public-but-undocumented
__libc_enable_secure variable which we can use.  Unfortunately, while
it *previously* worked to check this variable, a combination of newer
binutils and RPM break it:
http://www.openwall.com/lists/owl-dev/2012/08/14/1

So for now on Linux/glibc, we fall back to the historical Unix version
until we get glibc fixed.

On some BSD variants, there is a issetugid() function.  On other Unix
variants, we fall back to what GTK+ has been doing.

Reported-by: Sebastian Krahmer <krahmer@suse.de>
Signed-off-by: Colin Walters <walters@verbum.org>

NEWS

Detect MSG_NOSIGNAL and SCM_RIGHTS on OpenBSD

On OpenBSD, sys/socket.h requires sys/types.h to be included first.

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

Revert "cmake: use the same default system bus address as for autotools"

This reverts commit 05b0b9e65b6a58f0b0cb56d6ee8cf100061250b3.

Revert "Split DBUS_SESSION_BUS_DEFAULT_ADDRESS into listen, connect addresses and set better defaults"

This reverts commit b5d36dc27d1905d4d46ad7f0097f0ea0e0776adb.

On second thoughts, this is too big a change for a stable branch.

Split DBUS_SESSION_BUS_DEFAULT_ADDRESS into listen, connect addresses and set better defaults

On Unix, the connect address should basically always be "autolaunch:"
but the listen address has to be something you can listen on.

On Windows, you can listen on "autolaunch:" or
"autolaunch:scope=*install-path", for instance, and the dbus-daemon is
involved in the auto-launching process.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38201
Reviewed-by: David Zeuthen <davidz@redhat.com>
[default address changed to autolaunch: for interop with GDBus -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

cmake: use the same default system bus address as for autotools

The system bus is unsupported (and rather meaningless) on Windows anyway,
so we can use anything. Also, make it clear that it has to be a
"specific" address that can be listened on *and* connected to,
like unix:path=/xxx - a listen-only address like unix:tmpdir=/xxx or
nonce-tcp: would not be suitable.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38201
Reviewed-by: David Zeuthen <davidz@redhat.com>

NEWS

Define __EXTENSIONS__ on Solaris to get sockaddr_in6 and sockaddr_storage

[smcv: comments updated, commit message added]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=53286

Check HAVE_DECL_LOG_PERROR with #if, not #ifdef

It's always defined.

[smcv: commit message added]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=53286

1.6.5

Prepare 1.6.4 release

Fix launching of dbus-daemon on Windows in paths containing spaces

If dbus is installed in a path, which contains a space, dbus-launch will
not launch the daemon. That is so, because a command line is built from
just the path to the daemon and a parameter. The path has to be
surrounded with quotes. This can be done unconditionally, because the
quotes do not cause any trouble even if they are not needed.

Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=49450

NEWS

Set enable-developer default to 'no'

Misplaced [] and () led to enable_developer=no being part of the
option's documentation instead of actually being the default value.

Regression in 1.6.2, caused by #34671.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51657
Bug-Debian: http://bugs.debian.org/680027
Reviewed-by: David Zeuthen <davidz@redhat.com>

DBusTransport: do not assert that autolaunch address is non-empty

dbus-launch can apparently return an empty address under certain
circumstances, and dbus_parse_address() in the next line will return
a nice DBusError for an empty address rather than aborting the process.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51657
Bug-Debian: http://bugs.debian.org/680027
Reviewed-by: David Zeuthen <davidz@redhat.com>

NEWS

Properly concat DBUS_CONSOLE_AUTH_DIR with username

This removes the assumption that DBUS_CONSOLE_AUTH_DIR ends with a
trailing /.

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

Resume development

Second go at 1.6.2

Revise NEWS to not mention --exit-with-x11

Still recommend --exit-with-session in documentation, --exit-with-x11 was reverted

Revert "dbus-launch: add --exit-with-x11 option"

This reverts commit fcc656d430f53ad62c25e41d7e7bd880cbb726a0.

Stop release preparation, --exit-with-x11 doesn't work

Prepare 1.6.2

Create /var/lib/dbus explicitly rather than as a side-effect

Since Automake 1.11.4, an empty localstatelib_DATA variable will not
create $(localstatelibdir) as a side-effect.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51406
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Lennart Poettering <lennart@poettering.net>

dbus_pending_call_set_notify: don't leave the connection locked on OOM

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51032
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Lennart Poettering <lennart@poettering.net>

NEWS

Enable Automake maintainer mode by default, but let distros disable it

See http://blogs.gnome.org/desrt/2011/09/08/am_maintainer_mode-is-not-cool/
for more information.

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

Set configure defaults from --enable-developer, not Automake maintainer mode

Automake maintainer mode isn't about whether you're a maintainer or not
(although its name would suggest that), it's about whether files that are
normally distributed in the tarball get regenerated. As such, it's
not really appropriate to use it to drive defaults for things like
assertions and extra test code.

The desired effect is that developers building from git normally get
tests and assertions, while distribution packagers don't.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34671
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>

NEWS

On Unix, link libdbus to a platform-specific threading library

On Linux, this is libpthread; on other Unixes, in principle it might be
called libpthreads or libthreads or something.

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

When not producing a dynamic library, define DBUS_STATIC_BUILD

When targeting Windows, linking against the static library requires
special effort to turn off DLL import/export processing. We normally
link some things against the dynamic library, but if we're not building
that, we'll have to link everything statically.

Based on patches from 'william' on fd.o #46367.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33973
Tested-by: René Berber <Rene.Berber gmail com>

NEWS

Document that dbus-launch is not dbus-run-session

Architectural assumptions inside dbus-launch mean that it is unsuitable
for use in contexts where a particular process's lifetime defines the
session, unless there is an out-of-band mechanism (like the X server)
which can signal the end of the session.

Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197

dbus-launch: revise recommendations and put them in an EXAMPLES section

The first thing we should talk about is how to get a D-Bus session in
your X session - that's the common case.

Secondarily, we can tell command-line addicts how to have a D-Bus session.
Do not recommend --exit-with-session here, since that polls (and reads
from) stdin, which is harmful to precisely those command-line users!
Until we have some better tool, the best we can do here is note that
the dbus-daemon is not automatically terminated.

Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197

dbus-launch: add --exit-with-x11 option

This is more suitable for distributions' Xsession scripts: it verifies
that X is already available, and so never results in an attempt to poll
stdin.

Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197

dbus-launch: if using X to define the session lifetime, do not poll stdin

dbus-launch --exit-with-session attempts to scope the session length
to various things:

- if DISPLAY points to an X server, exit when the X session ends
- if stdin is a terminal, exit when end-of-file is reached
- if both are true, exit when one of them happens, whichever is first
- if neither is true, fail

These are not particularly useful semantics: if the session is scoped to
the X session, then the terminal from which dbus-launch was launched
is irrelevant. This also causes practical problems when dbus-launch
consumes characters from the terminal from which it happens to have
been launched (some display managers, like slim and nodm, run users' X
sessions with stdin pointing to the terminal from which the init daemon
happens to have started the display manager during boot, usually tty1
on Linux).

Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197

document how the various processes in dbus-launch interact

Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197

Start 1.6.2 development

Fix distcheck with newer Doxygen: remove *.js, too, during uninstall

Fix distcheck: remove potentially-read-only files from builddir

During distcheck, the srcdir is read-only. During "make all", cp may
preserve the read-only status of the file copied from the srcdir,
resulting in failure to overwrite it with an identical file during
"make check" (which depends on all-local).

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Prepare version 1.6.0 (new stable branch)

_dbus_transport_new_for_tcp_socket: add missing commas to address

Ralf pointed out that the address doesn't round-trip correctly.

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

Remove duplicate nonce-tcp (service-side) transport on Windows

Turns out this was duplicated too. We can just use the
platform-independent version, which uses the same code.

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

Remove duplicate nonce-tcp (client side) transport on Windows

_dbus_transport_open_socket is called before
_dbus_transport_open_platform_specific, and now handles nonce-tcp, so
this version is no longer useful.

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

Merge branch 'dbus-1.4'

Conflicts:
NEWS
dbus/dbus-internals.c
dbus/dbus-mainloop.c
dbus/dbus-sysdeps-unix.c
dbus/dbus-sysdeps-win.c
dbus/dbus-sysdeps.c
dbus/dbus-sysdeps.h

NEWS

use cp and mkdir -p instead of install within source tree

$(INSTALL) and $(INSTALL_DATA) try to change ownerships to root:bin when
copying tests to builddir. Presumably this is a difference in behaviour
between GNU and BSD install(1): the one in GNU coreutils doesn't try-and-fail
to change ownership if you're not root.

[Commit message added by smcv]

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

Avoid using monotonic time in the DBUS_COOKIE_SHA1 authentication method

When libdbus-1 moved to using monotonic time support for the
DBUS_COOKIE_SHA1 authentication was broken, in particular
interoperability with non-libdbus-1 implementations such as GDBus.

The problem is that if monotonic clocks are available in the OS,
_dbus_get_current_time() will not return the number of seconds since
the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus
specification. If both peers are using libdbus-1 it's not a problem
since both ends will use the wrong time and thus agree. However, if
the other end is another implementation and following the spec it will
not work.

First, we change _dbus_get_current_time() back so it always returns
time since the Epoch and we then rename it _dbus_get_real_time() to
make this clear. We then introduce _dbus_get_monotonic_time() and
carefully make all current users of _dbus_get_current_time() use it,
if applicable. During this audit, one of the callers,
_dbus_generate_uuid(), was currently using monotonic time but it was
decided to make it use real time instead.

Signed-off-by: David Zeuthen <davidz@redhat.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580

Avoid using monotonic time in the DBUS_COOKIE_SHA1 authentication method

When libdbus-1 moved to using monotonic time support for the
DBUS_COOKIE_SHA1 authentication was broken, in particular
interoperability with non-libdbus-1 implementations such as GDBus.

The problem is that if monotonic clocks are available in the OS,
_dbus_get_current_time() will not return the number of seconds since
the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus
specification. If both peers are using libdbus-1 it's not a problem
since both ends will use the wrong time and thus agree. However, if
the other end is another implementation and following the spec it will
not work.

First, we change _dbus_get_current_time() back so it always returns
time since the Epoch and we then rename it _dbus_get_real_time() to
make this clear. We then introduce _dbus_get_monotonic_time() and
carefully make all current users of _dbus_get_current_time() use it,
if applicable. During this audit, one of the callers,
_dbus_generate_uuid(), was currently using monotonic time but it was
decided to make it use real time instead.

Signed-off-by: David Zeuthen <davidz@redhat.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580

1.5.13

Prepare dbus 1.5.12

Build _dbus_string_starts_with_c_str even if not building tests

It's used by the own_prefix implementation.

Merge remote-tracking branch 'alban/own_prefix2'

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