This is a partial revert of b248f3481ced. Eventually, this commit can be
dropped once `objcopy --help` doesn’t exit with a non-zero status on
FreeBSD.
See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2360#note_1318608
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
meson in git master now warns about a missing `check:` kwarg, and may
eventually change the default from false to true.
Take the opportunity to require `objcopy --help` to succeed -- it is
unlikely to fail, but if it does something insane happened.
We used to use a pipe for the dbus daemon stdout to read the defined
address, but that was already requiring a workaround to ensure that dbus
daemon children were then able to write to stdout.
However the current implementation is still causing troubles in some
cases in which the daemon is very verbose, leading to hangs when writing
to stdout.
As per this, just don't handle stdout ourself, but use instead a
specific pipe to get the address address. That can now be safely closed
once we've received the data we need.
This reverts commit d80adeaa960ddfa13837900d0391f9bd9c239f78.
Fixes: #2537
The code in `g_dbus_message_new_from_blob()` has now been fixed to
correctly error out on all truncated messages, so there’s no need for an
arbitrary programmer error if the input is too short to contain a valid
D-Bus message header.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2528
Perform strict bounds checking when reading data from the D-Bus message,
and propagate errors to the callers.
Previously, truncated D-Bus messages could cause out-of-bounds reads.
This is a security issue, but one which is only exploitable when
communicating with an untrusted peer (who might send malicious
messages). Almost all D-Bus traffic is with a session or system bus,
where the dbus-daemon or dbus-broker is trusted, and is known to have
already rejected malformed (malicious) messages.
Accordingly, this is only exploitable with peer-to-peer D-Bus
conversations with an untrusted peer.
(Includes some minor cleanups from Philip Withnall.)
oss-fuzz#17408
Fixes: #2528
This introduces no functional changes; it only simplifies the code.
Instead of maintaining a separate pointer to the backend iff it’s a
`GDelayedSettingsBackend`, just test the `backend` pointer’s type.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2426
Previously, the delay-apply status of the parent `GSettings` object
would be partially inherited: `settings->priv->backend` in the child
`GSettings` object would point to a `GDelayedSettingsBackend`, but
`settings->priv->delayed` would be `NULL`.
The expectation from https://bugzilla.gnome.org/show_bug.cgi?id=720891
was that `get_child()` would fully inherit delay-apply status.
So, ensure that `settings->priv->delayed` is correctly set to point to
the delayed backend when constructing any `GSettings`. Update the tests
to work again (presumably the inverted test was an oversight in the
original changes).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2426
`g_settings_reset()` changes the value of the setting to `NULL`;
`add_to_tree()` was not handling that correctly.
Add a unit test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2426
Fix another variant of the previous commit, this time specific to the
idle callback of a method call on a subtree object, racing with
unregistration of that subtree.
In this case, the `process_subtree_vtable_message_in_idle_cb()` idle
callback already has a pointer to the right `ExportedSubtree` struct,
but again doesn’t have a strong reference to it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
If `g_dbus_connection_unregister_object()` (or `unregister_subtree()`)
was called from one thread, while an idle callback for a method call (or
a property get or set) was being invoked in another, it was possible for
the two to race after the idle callback had checked that the
object/subtree was registered, but before it had finished dereferencing
all the data related to that object/subtree.
Unregistering the object/subtree would immediately free the data,
leading the idle callback to cause a use-after-free error.
Fix that by giving the idle callback a strong reference to the data from
inside the locked section where it checks whether the object/subtree is
still registered.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2400
This is needed for an upcoming change which decouples their lifecycle
from their presence in the `map_id_to_ei` and `map_id_to_es` hash
tables.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
Move it further up the file, but make no changes to it. This will help
with a subsequent commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
Relax assertion about opened registry key as it may have been removed
in the meantime between enumeration and when opening, or (more likely)
we may not have the required permissions to open the some enumerated
keys (i.e. RegOpenKeyExW fails and returns ERROR_ACCESS_DENIED).
Fixes https://gitlab.com/inkscape/inbox/-/issues/5669
The "recursive:" kwarg is available in the targeted minimum version of
meson, and is basically required if you want to not emit warnings and
maybe error with --fatal-meson-warnings.
The current default behavior is false, so explicitly opt in to that value.
None of these internal libraries use recursive objects anyway.
In commit c74d87e44038925baf37367ce124c027e225c11e we went a different
route, and upgraded the minimum meson version and dropped the TODO
workarounds in these files. But for a stable branch this is not
desirable.
Instead of calling xterm when it clearly does not exist and causes a silent error,
inform the user that the launch failed so they can take the right action.
If the first power-profile installed test fails (for example, because
xdg-desktop-portal isn’t available), correctly tear down the dbusmock
object, or it will cause setUp() to fail when the next test in the suite
is run.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2481
When first creating the monitor, correctly set its property value to the
value from the portal, rather than waiting for the portal value to
change to set it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2481
We were lucky that this worked in some cases (the test is racy), but we
should actually run the condition check each loop, rather than when the
function is called.
Spotted by Martin Pitt:
96a8c02d24 (r54773831)
