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>
The original code of 'ProgressNotification' had a wrong closing tag,
which should use '</signal>' instead of '</method>'
Signed-off-by: Yen-Chin, Lee <coldnew.tw@gmail.com>
This appears to have been a copy/paste mistake. If only blanks (defined as
spaces or tabs) were removed, then it cannot be right to check for white
space (defined as spaces, tabs, carriage return or linefeed) afterwards.
If libdbus was compiled with assertions enabled, then this is a
denial-of-service issue for dbus-daemon or other users of DBusServer:
an unauthenticated user with access to the server's socket can send
whitespace that triggers this assertion failure. We recommend that
production versions of dbus, for example in OS distributions, should be
compiled with checks but without assertions.
[smcv: expanded commit message]
Thanks: Evgeny Vereshchagin
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/421
Test it's possible to consume libdbus as a subproject.
Suggested-by: Simon McVittie <smcv@collabora.com>
Signed-off-by: Daniel Wagner <dwagner@suse.de>
On Gitlab-CI we're always running the overall script as root (and
therefore we'll only enter the code path to re-run as non-root),
but when using these scripts for manual testing they might be run as
non-root to begin with.
Signed-off-by: Simon McVittie <smcv@collabora.com>
