Since meson 0.54.0, it is possible to override a dependency name,
so do that to make it easy to use dbus as a subproject. After this
change, simply
dependency('dbus-1')
will fall back to the subproject automatically and there is no need
for using `fallback` keyword argument. Of course this assumes that
the dbus source tree is at subprojects/dbus-1 and not subprojects/dbus
but it is easy to achieve that.
If the dbus source tree for some reason needs to be at subprojects/dbus,
dependency('dbus-1', fallback: 'dbus')
may be used, which still has the advantage of not needing to
depend on the variable names in the dbus build definitions.
This gives us coverage for Meson mingw-w64 by default, but
cross-compiling from Debian with MSVCRT rather than a native compilation
on Windows with UCRT. When combined with "windows msys64 ucrt64 cmake",
this fills in most of the missing coverage caused by disabling
windows-meson-mingw-ucrt64 to work around dbus#462.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Workaround for dbus#462: if this doesn't run reliably as a result of
external factors, then we shouldn't be using it as a CI gate.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Due to an adaptation of an rpm macro for cross-compiling with cmake, there
was a problem with the previous method of using the current directory as
the build directory. Instead, the command line options provided by cmake
are now used to define the source and build directories, which provide more
stable behavior.
Fix#455
Some labels are only used when checks are enabled, and some variables
are only used when assertions and/or checks are enabled. Instead of
cluttering the code with extra #ifdefs, we silence those warnings:
they're harmless in this case. We already do this in Autotools.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Linux generally declares syscalls with flags as type int. It's the same
ABI, but a slightly different API, and it seems better for our fallback
definition to match it exactly.
Related to dbus/dbus#453.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Some of the symbols we check for, such as close_range(), are only
declared in their corresponding header files if _GNU_SOURCE was
defined.
Resolves: dbus/dbus#453
Signed-off-by: Simon McVittie <smcv@collabora.com>
The exact failure mode reported in dbus/dbus#457 is quite difficult
to achieve in a reliable way in a unit test, because we'd have to send
enough messages to a client to fill up its queue, then stop that client
from draining its queue, while still triggering a message that gets a
reply from the bus driver. However, we can trigger the same crash in a
slightly different way by not allowing the client to receive a
particular message. I chose NameAcquired.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Normally, it's enough to rely on a message being given a serial number
by the DBusConnection just before it is actually sent. However, in the
rare case where the policy blocks the driver from sending a message
(due to a deny rule or the outgoing message quota being full), we need
to get a valid serial number sooner, so that we can copy it into the
DBUS_HEADER_FIELD_REPLY_SERIAL field (which is mandatory) in the error
message sent to monitors. Otherwise, the dbus-daemon will crash with
an assertion failure if at least one Monitoring client is attached,
because zero is not a valid serial number to copy.
This fixes a denial-of-service vulnerability: if a privileged user is
monitoring the well-known system bus using a Monitoring client like
dbus-monitor or `busctl monitor`, then an unprivileged user can cause
denial-of-service by triggering this crash. A mitigation for this
vulnerability is to avoid attaching Monitoring clients to the system
bus when they are not needed. If there are no Monitoring clients, then
the vulnerable code is not reached.
Co-authored-by: Simon McVittie <smcv@collabora.com>
Resolves: dbus/dbus#457
It appears some freedesktop CI runners still have /builds/dbus/dbus
owned by a different user ID.
This reverts commit 3f6400b8b9.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The dbus maintainers can open confidential merge requests by using a
private git repository, but other contributors (including most security
researchers) cannot, so the safest simple recommendation is no merge
requests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
* Add meson build instructions and reorder the README sections
* Fix a small typo for the security section
Signed-off-by: Ahmed Abdelfattah <a.abfattah@gmail.com>
procfs has special semantics: most files are 0 size,
only one read can be done on a file, and they are
not larger than 4MB. Enhance _dbus_file_get_content()
so that we can read files from /proc with it.
Signed-off-by: Luca Boccassi <bluca@debian.org>
dbus-internals.h already defines a macro which expands to the name
of the current function based on C standard version, etc. So use
that instead of hard-coding `__FUNCTION__`.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
dbus-internals.h already defines a macro which expands to the name
of the current function based on C standard version, etc. So use
that instead of hard-coding `__FUNCTION__`.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Previously, `retstr` would not be freed when `_dbus_string_append_len()`
or `_dbus_string_steal_data()` failed.
Fix those by:
* jumping to `_dbus_string_free()` when `_dbus_string_append_len()` fails
* ignoring the return value of `_dbus_string_free()`.
The latter works because in case of failure, `ret` will be set
to NULL by `_dbus_string_steal_data()`.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
These are extremely slow (the image build is currently at 36 minutes
and still running) which is standing in the way of us having functional
CI at all. They can be re-enabled if someone will maintain them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Repeatedly re-running each test with different malloc() calls failing
is really slow, and in particular this is making
dbus:dbus / marshal-recursive time out on freedesktop.org CI.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In practice the pipeline is going to fail for namespaces other than
dbus, so don't waste time on trying to run it there; only run the
detached pipeline for the MR.
Signed-off-by: Simon McVittie <smcv@collabora.com>
After abuses of fdo infrastructure were mitigated in
freedesktop/freedesktop#540, contributors cannot usually run pipelines
in their own forks of dbus.
Signed-off-by: Simon McVittie <smcv@collabora.com>
