Being able to determine that a certificate chain is invalid is not
considered an error, but success. This might not be obvious at first
due to the way the method is named and described currently. Since we
cannot change the name, let's improve the description and clarify this
aspect of its behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=780310
g_dbus_proxy_get_cached_property() and
g_dbus_proxy_get_cached_property_names() can both return NULL if the
property cache is empty. Avoid a crash if this situation arises (which
it looks like it could, from reading the code) by gracefully bailing out
on NULL return values.
Coverity issues: #1257044, #1257045https://bugzilla.gnome.org/show_bug.cgi?id=741229
socket->priv->timeout is only a guint, and the multiplication is
performed before it’s widened to gint64 to be stored in start_time
(thanks, C). This means any timeout of 50 days or more would overflow.
Fixing this bug makes me feel a real sense of self-worth.
Coverity ID: 1159478
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This will help us break generic GType deadlocks between people using
GDBus in different threads (which is supported), not just by GType
usage in the GDBus thread.
This should fix the common cases we're seeing in the wild, although I
have some lingering concerns that if someone e.g. referenced
e.g. `G_TYPE_DBUS_AUTH_MECHANISM_SHA1` etc. we'd need to add those
too.
https://bugzilla.gnome.org/show_bug.cgi?id=674885
These calls cause race warnings from tsan, but are not a thread safety
problem, because we can only ever observe single bit changes: all
modifications to the GSource.flags field are done with a lock held; all
reads are of independent fields, so no intermediate state can ever be
observed. This assumes that a non-atomic read will consistently give us
an old value or a new value.
In any case, these g_source_is_destroyed() calls can happen from any
thread, and the state could be changed from another thread immediately
after the call returns; so the checks are pointless. In addition,
calling g_source_set_ready_time() or g_source_destroy() on a destroyed
source is not a problem.
https://bugzilla.gnome.org/show_bug.cgi?id=778049
Calling the D-Bus method for the OpenURI portal "protects" the logic from
not ever having the remote method running in case the xdg-desktop-portal
process is not yet running and the caller quits quickly after the call.
This should not be a problem as the method returns immediately (regardless
of the user making a selection), but making it synchronous would prevent
situations where the OpenURI method would never be called because of D-Bus
dropping the message after the caller dies, without explicitly waiting for
a reply.
https://bugzilla.gnome.org/show_bug.cgi?id=780441
We currently assume that the OpenURI portal should be used
unconditionally when running inside a flatpak sandbox. While
the portal is what we usually want, there are exceptions:
Yelp is now included in the GNOME runtime to allow displaying
help without exporting the user documentation, and the sandboxed
app itself may register a scheme handler.
To account for those cases transparently, always try the normal
code path first and only fall back to calling the portal when
that fails.
https://bugzilla.gnome.org/show_bug.cgi?id=780471
Actually, Unicode changes to this file got reverted in
2d56c49b10. Also, there is
"No such interface '%s'" string already, so we avoid
breaking the string freeze.
This is an implementation of most of GAppInfo using the OS X
NSBundle APIs.
Missing at this point are things that don't have equivalents
in OS X, such as hidden desktop files, last-used, manual type
associations, and g_app_info_get_all().
https://bugzilla.gnome.org/show_bug.cgi?id=734946
This is an implementation of most of GContentType using the OS X
UTType APIs.
Missing at this point is an implementation of
g_content_types_get_registered() and g_content_type_guess_for_tree().
https://bugzilla.gnome.org/show_bug.cgi?id=734946
Previously, _kh_cancel_sub assumed that it only needed to call
_km_remove if sub did not exist in subs_hash_table. This is erroneous
because the complementary operation, _km_add_missing, can be called
from process_kqueue_notifications, in which context sub can *only* have
come from subs_hash_table.
Since _km_remove is implemented using g_slist_remove, which is
documented to be a noop if the list does not contain the element to be
removed, it is safe to call _km_remove unconditionally here.
https://bugzilla.gnome.org/show_bug.cgi?id=778515
On the warning/critical error handling paths for g_settings_set(), the
GVariant value was not ref-sunk, and the schema key was leaked. This
won’t affect code in production (unless it’s seriously buggy), but
eliminates some leaks from the error testing paths in the GSettings
tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
Spotted while running `make check` under Valgrind. While it’s not
necessary to fix memory leaks in glib-compile-schemas (since it’s a
utility which runs briefly then exits), fixing them makes more
legitimate leaks in the Valgrind output more obvious, and means we can
be sure there aren’t leaks in the underlying GLib/GIO code which
glib-compile-schemas is calling.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
When unregistered extension point (i.e. NULL pointer) is passed
to `g_io_extension_point_get_extensions`, it causes a segfault.
This commit adds an assertion, to prevent this.
https://bugzilla.gnome.org/show_bug.cgi?id=779183
Happens when the waiting-for-auth state is re-entered:
SERVER_STATE_WAITING_FOR_AUTH
|
v
G_DBUS_AUTH_MECHANISM_STATE_REJECTED
|
v
SERVER_STATE_WAITING_FOR_AUTH
Causing the previous `mech` pointer to get overwritten.
https://bugzilla.gnome.org/show_bug.cgi?id=778991
We're first getting the notification by its notify_id, but activating
the action afterwards could redraw it, leading to a dangling pointer.
Fix this by simply searching the list of active notifications again
after activating the action.
GNOME Builder's code was assuming that setting the launcher's
environ to NULL makes the subprocess have an empty environment, but in
fact the parent process's variables are still inherited because execv is
used instead of execve when envp is NULL. This commit clarifies the
documentation to make the behavior clear.
https://bugzilla.gnome.org/show_bug.cgi?id=778422
