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>
When compiling statically against the system-provided gettext on Mac OS
X, GLib needs to be linked against CoreFramework, which provides some
functions used by gettext.
Fix this by including the necessary macro magic from upstream gettext.
https://bugzilla.gnome.org/show_bug.cgi?id=725894
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
Now that the old logging API forwards through to the new structured
logging API, we don’t need to check the level or domain of a message
against INFO_LEVELS or G_MESSAGES_DEBUG — just pass it straight through
to the new structured logging API writer function.
https://bugzilla.gnome.org/show_bug.cgi?id=775879
If encoding with small chunks such that the call to
g_base64_encode_close() has to deal with 0 < x < 24 bits of remaining
state, the encoding code would not correctly use zeroes to pad out the
state — it would use left-over state from an earlier iteration in the
encoding process.
This resulted in invalid base-64 encodings.
Add a unit test for incremental encoding using different sized chunks
too.
Thanks to Rainier Perske for reporting and analysing the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=780066
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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
For versions of GCC which support it (≥ 4), define G_MODULE_EXPORT as
__attribute__((visibility("default"))). This is normally a no-op, unless
compiling with -fvisibility=hidden, in which case it marks a symbol to
be publicly exported from the library, which is what G_MODULE_EXPORT is
for. Previously G_MODULE_EXPORT has only worked on Windows.
The compatibility check for whether the compiler supports
__attribute__((visibility)) is based on the __GNUC__ define, and is
similar to the check done in configure.ac for defining G_GNUC_INTERNAL.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=778287
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
The custom build rules did not have rules for x64 Debug builds during
the refactoring. Fix this by removing all Platform and Configuration
conditions for it, since this is done on are configs in the same manner.
Noted by Ignacio Casal Quinteiro.
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
The tzdata maintainers had previously invented abbreviations for
timezones. As of their 2017a release, the one we were testing ("BRT")
has been dropped.
Switch to testing PST, which is a real timezone abbreviation.
https://bugzilla.gnome.org/show_bug.cgi?id=779799
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.
