No functional change, just removing some nesting. The check for whether
signal_data->subscribers is empty changes from a conditional that tests
whether it is into an early-return if it isn't.
A subsequent commit will add additional conditions that make us consider
a SignalData to be still in use and therefore not eligible to be removed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
No functional changes, except that the implicit ownership-transfer
for the rule field becomes explicit (the local variable is set to NULL
afterwards).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Subsequent changes will need to access these data structures from
on_worker_message_received(). No functional change here, only moving
code around.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Using these is a bit more clearly correct than repeating them everywhere.
To avoid excessive diffstat in a branch for a bug fix, I'm not
immediately replacing all existing occurrences of the same literals with
these names.
The names of these constants are chosen to be consistent with libdbus,
despite using somewhat outdated terminology (D-Bus now uses the term
"well-known bus name" for what used to be called a service name,
reserving the word "service" to mean specifically the programs that
have .service files and participate in service activation).
Signed-off-by: Simon McVittie <smcv@collabora.com>
On GNOME/glib#3268 there was some concern about whether this would
allow an attacker to send signals and have them be matched to a
GDBusProxy in this situation, but it seems that was a false alarm.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This somewhat duplicates test_connection_signals(), but is easier to
extend to cover different scenarios.
Each scenario is tested three times: once with lower-level
GDBusConnection APIs, once with the higher-level GDBusProxy (which
cannot implement all of the subscription scenarios, so some message
counts are lower), and once with both (to check that delivery of the
same message to multiple destinations is handled appropriately).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Technically we can’t rely on it being kept alive by the `message->body`
pointer, unless we can guarantee that the `GVariant` is always
serialised. That’s not necessarily the case, so keep a separate ref on
the arg0 value at all times.
This avoids a potential use-after-free.
Spotted by Thomas Haller in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3720#note_1924707.
[This is a prerequisite for having tests pass after fixing the
vulnerability described in glib#3268, because after fixing that
vulnerability, the use-after-free genuinely does happen during
regression testing. -smcv]
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3183, #3268
(cherry picked from commit 10e9a917be7fb92b6b27837ef7a7f1d0be6095d5)
The `g_content_type_guess_for_tree` function segfaults currently when
processing filenames that are not valid unicode strings. Let's use the
`g_filename_to_utf8` and `g_utf8_make_valid` functions before other
processing to prevent that.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/3168
(cherry picked from commit 41af42717531a2af6dfd7a4f7b5c5fc228e85f0d)
This is just the result of running `black $(git ls-files '*.py')`.
For some reason, the `sh-and-py-check` CI job didn’t run on merge
request !3751, so this non-standard formatting slipped through onto
`main`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3754#note_1939914
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This fixes a stack overflow reported by a user who had both the
definition of text/javascript from shared-mime-info 2.3 and the
definition of text/javascript from shared-mime-info 2.4 installed at the
same time. In 2.3, text/javascript is a subtype of
application/ecmascript, but in 2.4 application/ecmascript is a subtype
of text/javascript. Having both at the same time resulted in circular
inheritance.
The new logic keeps a list of all parents that have already been
checked, which is more comprehensive than the old workaround that was
implemented in commit 38869ece2 ("xdgmime: Prevent infinite loops from
badly-formed MIME registrations").
https://bugs.archlinux.org/task/80279
Depending on the operating system, /bin/sh might either be bash (for
example on Fedora or Arch) or dash (for example on Debian or Ubuntu)
or some other POSIX shell.
When bash is asked to run a simple command with no shell keywords or
metacharacters, like this one, it replaces itself with the program
via execve(), but dash does not have that optimization and treats it
like any other program invocation in a larger script: it will fork,
exec the program in the child, and wait for the child in the parent.
This seems like it conflicts with sleep_and_kill() assuming that it can
use the subprocess's process ID as the sleep(1) process ID. Specifically,
if it sends SIGKILL, it will go to the sh(1) process and not the sleep(1)
child, which could result in the sh(1) process being terminated and
its sleep(1) child being leaked.
To get the bash-like behaviour portably, explicitly use the exec builtin
to instruct the shell to replace itself with sleep(1), so that the
process ID previously used for the shell becomes the process ID of the
sleep process.
This appears to resolve an intermittent hang and test timeout on Debian
machines (especially slower ones), although I'm not 100% clear on the
mechanics of how it happens.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3157
Signed-off-by: Simon McVittie <smcv@collabora.com>
The PTRACE_O_EXITKILL symbol in sys/ptrace.h is an enum member, not
a macro. The #ifdef check added to the GSubprocess test-case in
272ec5dbca8ec957ced2cdca45bde69f47fb4df9 will not detect it.
Use cc.has_header_symbol() to properly detect it. According to the
documentation: "Symbols here include function, variable, #define,
type definition, etc.".
Fixes: 272ec5dbca8ec957ced2cdca45bde69f47fb4df9
Closes: https://gitlab.gnome.org/GNOME/glib/-/issues/3156
Commit f6c40b1d fixed libelf detection on FreeBSD (where the library has
no pkg-config file and needs to be found via `find_library()`), but
broke `-Dlibelf=disabled` on Linux, as `get_option('libelf')` was no
longer checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3120
It’s not actually needed on any platform, and causes compilation
problems on platforms where it’s not available.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3111
When setting the file time using utimensat, don't ignore
microseconds for access/modify times. By doing that, they're preserved
when using g_file_info_set_modification_date_time and then setting the file's
attributes from it.
Fixes#3116
Make sure to fail consistently in case people created a GPropertyAction
with g_object_new() without passing a property name.
Bindings that construct objects with g_object_new() have no idea if a
property is mandatory.
See: #3130
This avoids a critical warning from trying to disconnect a signal
handler from a `NULL` object if `paction->object` is `NULL` for whatever
reason (see: the following commit).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #3130
I had thought that because `g_source_destroy()` was called for the two
sources (cancel and timeout) in the `GTask` finalize function for a
threaded resolver operation, that it would be fine to use a plain
pointer in the source callbacks to point to the `GTask`.
That turns out to not be true: because the source callbacks are executed
in the GLib worker thread, and the `GTask` can be finalized in another
thread, it’s possible for a source callback (e.g. `cancelled_cb()`) to
be scheduled in the worker thread, then for the `GTask` to be finalized,
and then the source callback to continue execution and find itself
doing a use-after-free.
Fix that by using a weak ref to the `GTask` in the source callbacks,
rather than a plain pointer.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3105
The fields are fully validated in `validate_headers()` in
`gdbusmessage.c` now, so the connection code should be able to rely on
the required ones being non-`NULL`.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3061
`object_path` and `path` were doing exactly the same thing here.
This introduces no functional changes.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
We already validated that the required headers for each type of D-Bus
message were present. However, we didn’t validate that they contained a
variant of the right type. This could lead to functions like
`g_dbus_message_get_path()` returning `NULL` unexpectedly.
This failure could only be hit when using GDBus in peer-to-peer mode, or
with a D-Bus server which didn’t validate the headers itself. The
reference D-Bus server does validate the headers, and doesn’t forward
invalid messages to clients.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3061
