freedesktop.org Gitlab doesn't currently have enough test runners
available to run all of this every time. For higher-risk changes
(for example those that change the build system) we can run the
complete set through the web UI.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit a2f416c289)
This uses the same shell scripts as Travis-CI, with slightly different
settings. We use Docker containers for all our Gitlab-CI runs, so take
the opportunity to use Debian 9 'stretch' as our baseline, and
relegate Ubuntu 14.04 'trusty' to to a secondary build.
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 60933c09e9)
Travis-CI workers have cmake preinstalled, but Gitlab-CI Docker images
typically don't.
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 907832e008)
AddrPC.Offset is the same size as a pointer, but previously
we printed it as though it was the same size as a long,
which is 32 bits on 64-bit Windows.
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105662
(cherry picked from commit 577813cf3a)
Previously, on 64-bit Windows we were passing a 32-bit int where the
format string expects a 64-bit SOCKET.
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105662
(cherry picked from commit 18d4ff6644)
As noted in GLib commit c879f50f, gcc's interpretation of the malloc
attribute has become more strict over time, which could result in
miscompilation. The new definition is that in addition to assuming
that the returned memory block is newly-allocated, gcc now assumes
that it does not contain any valid pointers. This is OK for
uninitialized or zero-initialized memory returned by dbus_malloc()
or dbus_malloc0(), but not valid for dbus_realloc(), which might be
used for a dynamically-sized array of (structures containing)
valid pointers.
See https://gitlab.gnome.org/GNOME/glib/issues/1465
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107741
Running the "embedded tests" through valgrind revealed that before this
commit, we would have been willing to read up to 3 bytes off the end of
a message if the message is truncated part way through a boolean. Any
practical allocator will round up allocations to the next 32-bit (or
larger) boundary, so in practice this will not leave the memory buffer
(and in particular did not crash during unit testing), but it could read
uninitialized contents.
On little-endian CPUs, an attacker might be able to use this to learn
whether up to 3 bytes of uninitialized memory in the dbus-daemon
were all-zero (their crafted message would be relayed) or not (their
connection would be disconnected for sending an invalid message). On
big-endian CPUs, an attacker might be able to use this to learn whether
up to 3 bytes were all-zeroes (relayed to a cooperating peer), 0-2
bytes of all-zeroes followed by 0x01 (relayed to a cooperating peer),
or something else (disconnected). This is not believed to be exploitable
to leak interesting information.
Fixes: 62e46533 "hardcode dbus_bool_t to 32 bits"
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107332
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit e93a775e68)
If re-initializing the string fails, it will be left in a state
where it has a length of 0 and a NULL buffer. That's valid to
"free", but not valid to pass to rmdir().
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107194
(cherry picked from commit 294e8b0b67)
If an implementation fails to listen, and a subsequent implementation
succeeds, then we would have leaked this. Detected by running
tests/loopback.c under valgrind.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107194
(cherry picked from commit b14a4517a8)
Using strncpy (buffer, str, strlen (str)) is a "code smell" that
might indicate a serious bug (it effectively turns strncpy into
strcpy), and gcc 8 now warns about it. In fact we avoided the bug
here, but it wasn't at all obvious.
We already checked that path_len is less than or equal to
_DBUS_MAX_SUN_PATH_LENGTH, which is 99, chosen to be strictly less
than the POSIX minimum sizeof(sun_path) >= 100, so we couldn't
actually be overflowing the available buffer.
The new static assertion in this commit matches a comment above the
definition of _DBUS_MAX_SUN_PATH_LENGTH: we define
_DBUS_MAX_SUN_PATH_LENGTH to 99, because POSIX says struct
sockaddr_un's sun_path member is at least 100 bytes (including space
for a \0 terminator). dbus will now fail to compile on
platforms that are non-POSIX-compliant in this way, except for Windows.
We zeroed the struct sockaddr_un before writing into it, so stopping
one byte short of the end of sun_path ensures that we get \0
termination.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107350
Reviewed-by: Thiago Macieira <thiago@kde.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit f429631365)
The foreach(list, (DBusForeachFunction) free, NULL) idiom seems too
entrenched to remove it from stable branches.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107349
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
For example, this can be the case in bubblewrap or Debian pbuilder after
unsharing the network namespace:
bwrap \
--bind / / \
--dev-bind /dev /dev \
--bind /dev/shm /dev/shm \
--bind /dev/pts /dev/pts \
--unshare-net \
${builddir}/test/test-loopback --tap
...
ok 1 /connect/tcp # SKIP Name resolution does not work here:
getaddrinfo("127.0.0.1", "0", {flags=ADDRCONFIG, family=INET,
socktype=STREAM, protocol=TCP}): Name or service not known
On some systems this can be circumvented by using nss_wrapper from
<https://cwrap.org/nss_wrapper.html>:
cat > hosts <<EOF
127.0.0.1 localhost
EOF
bwrap \
... \
env \
LD_PRELOAD=libnss_wrapper.so \
NSS_WRAPPER_HOSTS=$(pwd)/hosts \
${builddir}/test/test-loopback --tap
...
# listening at tcp:host=127.0.0.1,port=39219,family=ipv4,guid=...
but for systems where that does't work, we should be prepared to skip
the affected tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
(cherry picked from commit f1faafd59b)
Pathological autobuilder environments might not list localhost in
/etc/hosts.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
(cherry picked from commit 4cfc7de30d)
Minimal autobuilder environments don't always have working TCP,
so we may need to skip TCP tests. Make sure we test the equivalent
code paths via Unix sockets in those environments.
One notable exception is test/fdpass.c, which uses TCP as a transport
that is known not to be able to carry Unix fds; this needs to continue
to use TCP.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
(cherry picked from commit cb7dd5bfcc)
This expands test coverage, and lets us reuse the test for other
address schemes.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
(cherry picked from commit b19c9e2f26)
getaddrinfo and getnameinfo have their own error-handling convention
in which the library call returns either 0 or an EAI_* error code
unrelated to errno. If the error code is not EAI_SYSTEM, then
the value of errno is undefined (in particular it might be carried
over from a previous system call or library call). Introduce a
new helper function _dbus_error_from_gai() to handle this.
The equivalent code paths in Windows appear to be OK: the Windows
implementation of getaddrinfo() is documented to return a Winsock
error code, which we seem to be handling correctly.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106395
(cherry picked from commit 60cedd0cfd)
Otherwise, distcheck fails when mallard-ducktype is available.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 9391d769ae)
This might (?) have made sense behind a firewall in 2003; but now it's
2018, the typical threat model that we are defending against has
changed from "vandals want to feel proud of their l33t skills"
to "organised crime wants your money", and a "trusted" local LAN
probably contains an obsolete phone, tablet, games console or
Internet-of-Things-enabled toaster with remote root exploits.
This make network topologies that used to be acceptable look
increasingly irresponsible.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit d0a16b59a8)
This is the default, and blocks TCP-based attacks by making the
attacker fail to authenticate (while also preventing inadvisable
TCP-based configurations from working).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit aef4475939)
I'm far from convinced that this option should even *exist*, but it
should definitely be documented as a very bad thing.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit 5d36804867)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add a TODO comment as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit cf47380641)
With some fairly reasonable threat models (active or passive local
attacker able to eavesdrop on the network link, confidential
information being transferred via D-Bus), secure authentication is
insufficient to make this transport secure: it does not protect
confidentiality or integrity either.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit 2513f84db6)
The old version-1 format is deprecated and now produces warnings.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106186
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add the .devhelp2 file to .gitignore as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit fa92263920)
The tutorial is not necessarily a great entry point for the libdbus
documentation: it's infrequently updated, and we should probably have
the "If you use this low-level API directly, you're signing up for some
pain" message from the API reference show up in devhelp more immediately.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106186
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add longer commit message with rationale]
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit c84ac8b1ef)
Newer versions of yelp-build use this instead of a jQuery syntax
highlighter.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106171
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Also add it to .gitignore as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 49ad5b110f)
