check_valid_fd() does not touch its second parameter if the fd is not,
in fact, a valid fd. Initialize the "out" parameter to the opposite
of the value we are hoping for, so that both assertions will fail if
there is a problem.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If passed an invalid DBusSystemLogSeverity, the default case for the
switch construct is to crash out with an assertion failure, but the
assertion failure itself is not compiled in if we are doing a production
build without assertions.
Detected by compiling with gcc 14, which does some static analysis
by default.
Signed-off-by: Simon McVittie <smcv@collabora.com>
A command like `dbus-test-tool spam --payload=abcde --bytes` could
previously have left the length uninitialized.
Detected by compiling with gcc 14.
Signed-off-by: Simon McVittie <smcv@collabora.com>
gcc 14 detects that port can be NULL here, which is technically invalid
to pass to printf (although many implementations print it as "(null)").
Becuase we're using getaddrinfo(), we treat a NULL service (port number
string) as a request to listen on "port 0", meaning we ask the kernel to
assign an arbitrary nonzero port for us; when printing addresses in
error messages, treating that as port 0 seems reasonable.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If I set a breakpoint on the call to _dbus_credentials_add_unix_uid
further down in this function and run the loopback test, I can see
that sometimes it's getting called with a uid of 4294967295. This is
not intended, but happens because the -1 value returned from
SO_PEERCRED is interpreted as a uid of 4294967295, because if uid_t is
unsigned, it won't be sign extended when assigned to uid_read.
As far as I can tell, every other API used in this function to get
uid/gid on some system returns an error when there's no credential
information (e.g. on a non-unix socket), rather than returning -1, so
they shouldn't have to do this check.
Fixes: 01af5ff4 ("add credentials support, add EXTERNAL auth mechanism")
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Unlike "bin", "tty" actually means something on modern Linux distros,
and is used by a default udev rule, so it's more likely to exist on
distros than a group that just exists for historical compatibility
with who knows what.
"tty" exists on macOS, Debian, and Fedora (the criteria used for
choosing "bin" in f2905def ("policy tests: Use bin rather than
nogroup, wheel, or root")), but also fixes running the bus test for me
on NixOS, which has "tty" but not "bin".
Closes: https://gitlab.freedesktop.org/dbus/dbus/-/issues/514
Signed-off-by: Alyssa Ross <hi@alyssa.is>
This is the name used previously by autoconf, and still used by the C
code. Presumably this meant that the launchd ended up never being
built with Meson, even if launchd support was enabled.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Fixes: cd2e3826 ("Add Meson build system")
These were/are used as autoconf/CMake variable names, but were never
used by C code, so there's no need to export them as macros.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Fixes: dca6591f ("Keep cmake defines GLIB_VERSION_... in sync with autotools.")
Fixes: cd2e3826 ("Add Meson build system")
It's a wrapper around snprintf(), so we are not gaining any efficiency
versus _dbus_string_append_printf(), and might as well use the more
general function instead. Doing it this way might even be a little *more*
efficient, since it reduces reallocations; it's certainly more concise.
Signed-off-by: Simon McVittie <smcv@collabora.com>
It's a wrapper around snprintf(), so we are not gaining any efficiency
versus _dbus_string_append_printf(), and might as well use the more
general function instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
D-Feet is no longer maintained and its closest replacement, as mentioned
in the D-Feet page https://wiki.gnome.org/Apps/DFeet, is d-spy.
The project description doesn't need to be updated because d-spy
provides the same set of features that D-Feet had.
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
gitlab.fd.o/bustle/bustle points to the old archived project. The new
version has been rewritten in Rust and is now hosted at
gitlab.gnome.org/World/bustle
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
Commit f20a05f60f included in dbus-1.15.0 broke autolaunch: on
Windows. autolaunch_custom_command_line_parameter shall be initalized
to null as it is later used in only one place in the code, with this
ternary:
autolaunch_custom_command_line_parameter ? autolaunch_custom_command_line_parameter : "--session"
Closes#503
When `dbus-daemon` sets more than 128 directories for `XDG_DATA_DIRS`,
none of the elements in `new_dirs` will be `NULL`, which resulted in
these loops reading out-of-bounds (undefined behaviour). In practice
this led to a crash.
To avoid this, make sure to stop iteration at the end of the array.
[smcv: Expanded commit message]
Resolves: dbus/dbus#481
instead of using has_header use check_header to confirm the header
works. This is necessary to get the meson build to work with Visual
Studio 2022. It has <stdatomic.h> but it does not actually work when
compiling a C program. A minimal C program that include <stdatomic.h>
fails with the following errors:
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(36): error C2061: syntax error: identifier 'atomic_bool'
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(36): error C2059: syntax error: ';'
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(37): error C2061: syntax error: identifier 'atomic_char'
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(37): error C2059: syntax error: ';'
...
...
check_header is consistent with CMake's
check_include_file(stdatomic.h HAVE_STDATOMIC_H)
which is why the CMake-based build of dbus works with Visual Studio
2022, while the meson build doesn't.
Fixes#494
Recent versions of glibc support C.UTF-8 natively, and both Debian and
openSUSE (which we use for our CI) have been patching it into our glibc
versions for several years before that.
Helps: https://gitlab.freedesktop.org/dbus/dbus/-/issues/488
Signed-off-by: Simon McVittie <smcv@collabora.com>
After running the test suite, we don't need (or want) to re-run the test
suite as a side-effect of producing a dist tarball. Historically, this
test-case used Autotools `make dist`, not `make distcheck`, but when
we removed the Autotools build system, it was replaced with
`meson dist` (similar to Autotools `make distcheck`). Change that to
`meson dist --no-tests`, which is more like Autotools `make dist` as
originally intended.
In particular, when we re-ran the test suite, we weren't filtering out
the time-consuming and timeout-prone tests that emulate malloc()
failures, which we don't normally intend to run in CI.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/489
Signed-off-by: Simon McVittie <smcv@collabora.com>
Before we removed the Autotools build system, these meant: do a
`make dist` with Autotools, then unpack the resulting tarball, and build
it with Meson or CMake (as appropriate). This was important because the
contents of an Autotools `make dist` differed significantly from what's
in git: only the files that were explicitly declared as sources in the
Autotools build system were distributed, and Autotools would also add its
own generated cruft.
Now that we're doing releases with Meson, the official source release
artifact is basically `git archive`, so there's much less need to
distinguish between official source releases and what's in git, and these
variant build systems became simple aliases for meson and cmake.
Remove those aliases from tools/ci-build.sh, and stop using them in
.gitlab-ci.yml.
Signed-off-by: Simon McVittie <smcv@collabora.com>
