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 d80adeaa96.
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
Since
https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/173,
there is now a really surprising implication to using a non-default
GTlsDatabase: your database could do nothing at all other than wrap the
default database, which you would expect to result in no behavior
changes, but in fact it causes fewer security checks to be performed
during certificate verification. This is because certificate
verification moved from GTlsDatabase to GTlsConnection, allowing for
more security checks to be performed. But if using a non-default
GTlsDatabase, we have to fall back to letting GTlsDatabase to the
verification, as before.
This is the best we can do. It's not a regression for applications,
because it means applications get the previous pre-2.72 behavior. But it
does mean that new security checks added in 2.72 are not applied, which
is unfortunate, so we should warn developers about this.
This feature has been reverted for now because I messed up the
implementation and it was doing sync I/O during async API calls. Oops!
Since it's not present in 2.70 nor in 2.72, let's remove the reference
to the exact GLib version that this behavior was introduced in. I'd like
to get it working properly for 2.74, but it's not ready yet and just
changing the version to 2.74 feels optimistic.
Rather than waiting for a fixed period of time, poll in a loop until the
condition the test is expecting is true.
A better solution would be to use a `GSource` and wait until that’s
dispatched. But doing so might affect the behaviour of the
`GInputStream` under test, so busy-wait instead.
Fixes this CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/1630758
```
(some socket debug output)
Bail out! GLib-GIO:ERROR:../gio/tests/converter-stream.c:1037:test_converter_pollable: assertion failed (res == -1): (1 == -1)
```
I could not reproduce the failure remotely with a few hundred
invocations of the test, so it might only present itself on BSD, which
presumably has different socket timing behaviour from Linux.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
gio/tests/gio-du.c: In function 'main':
gio/tests/gio-du.c:74:11: error: parameter 'argc' set but not used
74 | main (int argc, char **argv)
| ~~~~^~~~
gio/ginputstream.c: In function 'g_input_stream_real_skip':
gio/ginputstream.c:433:31: error: comparison of integer expressions of different signedness: 'goffset' {aka 'long long int'} and 'long long unsigned int'
433 | (start + count) > (guint64) end)
| ^
gio/gwin32appinfo.c: In function 'uwp_package_cb':
gio/gwin32appinfo.c:3383:17: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i = 0; i < supported_extgroups->len; i++)
^
gio/gwin32appinfo.c:3389:29: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_ext = 0; i_ext < grp->extensions->len; i_ext++)
^
gio/gwin32appinfo.c:3430:35: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_verb = 0; i_verb < grp->verbs->len; i_verb++)
^
gio/gwin32appinfo.c:3463:33: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_hverb = 0; i_hverb < ext->verbs->len; i_hverb++)
^
gio/gwin32appinfo.c:3478:17: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i = 0; i < supported_protocols->len; i++)
^
gio/gwin32appinfo.c:3541:33: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_hverb = 0; i_hverb < url->verbs->len; i_hverb++)
^
gio/gwin32appinfo.c: In function 'g_win32_app_info_launch_internal':
gio/gwin32appinfo.c:4799:37: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (p_index = 0; p_index <= g_strv_length (envp); p_index++)
^~
gio/gwin32packageparser.c: In function 'WIN32_FROM_HRESULT':
gio/gwin32packageparser.c:99:30: warning: comparison of integer expressions of different signedness: 'long unsigned int' and 'long int'
if ((hresult & 0xFFFF0000) == MAKE_HRESULT (SEVERITY_ERROR, FACILITY_WIN32, 0) ||
^~
This was previously done (by commit 63038d1e4c) in one of the cases
where `kill_test_service()` was called — but not the other.
This meant that one instance of `gdbus-testserver` could still be
around when (as it happens, due to the order of the tests) the
`/gdbus/proxy/no-match-rule` test was run. It would start a second
instance of `gdbus-testserver`, which would exit early due to the test
name still being owned on the bus. The first (killed) instance of
`gdbus-testserver` would then exit, leaving no test servers running, and
hence the new test would fail.
This was being seen as frequent CI failures, particularly on FreeBSD
(must have slightly different timing for process signalling and
termination from Linux).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Once upon a time, we tried to return all possible certificate errors,
but it never actually worked reliably and nowadays we have given up.
This needs to be documented because a reasonable developer would not
expect it.
Because mistakes could be security-critical, I decided to copy the same
warning in several different places rather than relying only on
cross-referencese.
These are known leaks, as they were being done in tests which were
checking precondition failures.
However, since we know what happens when the failures occur, we can
still free the input data reliably, so do that.
This improves the valgrind output for `actions` to show zero definite
leaks.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The `actions` test previously waited an arbitrary 100ms for various
D-Bus messages to be sent/received, before checking the results of those
messages.
Normally, this would work, but on heavily loaded CI systems, it would
sometimes fail. For example,
https://gitlab.gnome.org/GNOME/glib/-/jobs/1611701.
Fix that by waiting for the condition being checked to evaluate to true,
rather than waiting an arbitrary period of time. On faster machines,
this will speed the tests up too.
Assume that the global default `GMainContext` is in use, so a
`GMainContext*` pointer doesn’t have to be passed around.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
gio/gcontenttype-win32.c: In function 'get_registry_classes_key':
gio/gcontenttype-win32.c:66:78: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'int'
if (ExpandEnvironmentStringsW (wc_temp, wc_temp_expanded, len) == len)
^~
This allows the flag to allow interactive auth to be set. Previously, it
was unconditionally unset.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
D-Bus has an upper limit on number of Match rules and it's rather easy to hit
with a big number of proxies with signal subscriptions. This happens with
NetworkManager with hundreds of devices or connection settings. By passing
G_DBUS_SIGNAL_FLAGS_NO_MATCH_RULE to g_dbus_connection_signal_subscribe(), the
user can call AddMatch with a less granular match instead of a match per every
proxy.
Tests subsequently added by Philip Withnall.
Fixes: #1109
- Isolate the first meaningful paragraph, for gi-docgen's summary
- Describe get_object() as a binding API
- Fix reference to get_item() inside get_item_type()
g_check_setuid does more than setuid checks when using AT_SECURE.
Make sure that it is referenced in the error message to help
users debug in case or errors
Closes#2518
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
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
Add missing (nullable), and use 2-space indentation to avoid markdown
pre-formatted blocks when unwanted.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
As this would have undesirable consequence.
Quoting Philip Withnall:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2305#note_1294729:
The documentation never said anything about accepting absolute paths,
so any code which is relying on that is relying on undocumented
behaviour. We’re allowed to change that.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
`standard::name` must be available for `g_file_enumerator_get_child()`
to work. Emit a critical warning and return if it’s not. This is similar
to the existing behaviour in `g_file_enumerator_iterate()`.
Improve the documentation to mention this.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2507
The code cannot function correctly if the `standard::name` attribute is
not present, so upgrade the existing warning to a critical warning and
return if it fails in `g_file_enumerator_iterate()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2507
It was Red Hat specific when it was introduced in 2004, was never
supported by mount(8) upstream, and was removed entirely in 2008.
It’s confusing for GLib to keep references to it around.
Thanks to Karel Zak for digging up the history of it:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2298#note_1294519
And thanks to Xidorn Quan for looking into it in the first place (see
!2298).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
gio/gsocket.c: In function 'g_socket_get_available_bytes':
gio/gsocket.c:3141:17: warning: comparison of integer expressions of different signedness: 'u_long' {aka 'long unsigned int'} and 'int'
if (avail == -1)
^~
gio/gsocket.c: In function 'g_socket_send_messages_with_timeout':
gio/gsocket.c:5283:19: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i = 0; i < num_messages; ++i)
^
gio/gsocket.c:5308:76: warning: operand of ?: changes signedness from 'int' to 'gsize' {aka 'long long unsigned int'} due to unsignedness of other operand
result = pollable_result == G_POLLABLE_RETURN_OK ? bytes_written : -1;
^~
gio/win32/gwinhttpfile.c: In function 'g_winhttp_file_query_info':
gio/win32/gwinhttpfile.c:554:13: warning: comparison of integer expressions of different signedness: 'int' and 'size_t' {aka 'long long unsigned int'}
n == wcslen (content_length))
^~
gio/win32/gwin32fsmonitorutils.c: In function 'g_win32_fs_monitor_handle_event':
gio/win32/gwin32fsmonitorutils.c:107:11: warning: comparison of integer expressions of different signedness: 'GFileMonitorEvent' {aka 'enum <anonymous>'} and 'int'
if (fme != -1)
^~
gio/win32/gwinhttpvfs.c: In function 'g_winhttp_vfs_get_file_for_uri':
gio/win32/gwinhttpvfs.c:172:17: warning: comparison of integer expressions of different signedness: 'int' and 'long long unsigned int'
for (i = 0; i < G_N_ELEMENTS (winhttp_uri_schemes); i++)
^
gio/win32/gwinhttpvfs.c: In function 'g_winhttp_vfs_get_supported_uri_schemes':
gio/win32/gwinhttpvfs.c:210:17: warning: comparison of integer expressions of different signedness: 'int' and 'long long unsigned int'
for (i = 0; i < G_N_ELEMENTS (winhttp_uri_schemes); i++)
^
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.
There are two basic solutions to this problem:
- The current default behavior is false, so explicitly opt in to that
value. None of these internal libraries use recursive objects anyway.
- Use link_with to link to the static library directly, rather than the
extracted objects.
Option 2 is what used to be done before commit
62af03bda8, but it only works with meson
>=0.52 and previously had buggy behavior.
Since the minimum version of meson is now 0.52, it is safe to revert
that commit and go back to using link_with, and therefore option 2 is
chosen.
Previously, the code validated that child objects have a path with the
object manager strictly as a prefix. That doesn’t work in the case where
the object manager’s path is `/`. This case is not recommended, but is
supported.
If the object manager’s path is `/`, validate that child objects’ paths
are not equal to it. If they are equal to it, warn the user rather than
emitting a critical warning, since we can’t expect any users who’ve not
been compliant with the spec to instantly rework their D-Bus APIs.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2500
Emit this when we're about to spawn or DBus activate a GAppInfo. This
allows lauchers to keep the appinfo associated with a startup id.
We use a GVariant to allow for future exansion of the supplied data.
When using g_desktop_app_info_launch_uris_as_manager the "launched"
signal allows to map a desktop-startup-id to a GAppInfo. Make this
possible for DBus activation too.
Since we don't have a PID there we pass a 0. Update the signal
description accordingly.
These should be implemented by loadable IO module libraries, but are not
callable in GLib itself.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2498
This is a partial revert of commit
f378352051, as the previous commits have
silenced the AddressSanitizer warnings for `GContentType`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2310
The function pointer casts silence the compiler and allow the code to
build (and even run in the typical case). However, when building with
control flow integrity checks, the runtime (rightfully) complains about
calling a function via a mismatched function pointer type.
In order to make xdgmime properly relocatable so that unit tests can use
it without it reading and modifying the user’s actual xdgmime files, and
without the need to call setenv() (and get tied up with thread safety
problems), add a xdg_mime_set_dirs() method to allow the dirs to be
overridden. They will still default to the values of $XDG_DATA_HOME and
$XDG_DATA_DIRS.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Allocate an empty cache object, check cache objects for being empty
before using them.
Otherwise the code will re-read cache every 5 seconds, as NULL cache
does not trigger the code that stores mtime, which makes the cache
file appear modified/unloaded permanently.
https://bugzilla.gnome.org/show_bug.cgi?id=735696
Since returning exactly one match has special significance, don't
give up matching before we've found at least 2 types. Also, make
sure that we don't return the same mime type more than once.
Bug 541236.
If an `InterfacesRemoved` signal is received for an object which doesn’t
exist in the local map of interfaces, don’t emit a warning.
This seems to happen in the real world (see #2401). Without a trace of
the D-Bus traffic it’s not possible to know exactly what situation is
causing this, but it seems possible that the peer could disappear and
its `notify::name-owner` signal could be processed before its
`InterfacesRemoved` signal, or something similar.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2401
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
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.
Also added (transfer full) or (transfer none) annotations while I was at it.
This is the result of checking each `Returns:` line in these files. I’ve
only considered nullability and transferability, and not other (potentially
missing or incorrect) annotations.
Helps: #2227
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)
Let's explain the advantages of relying on GTlsConnection to perform
certificate verification.
Also, document that the issuer property is a little tricky, because the
issuer certificate might not be the certificate that actually gets used
in final certification path building. This is very unexpected to anybody
who is not an expert.
Because TLS certificate verification is extremely complex, the lookup
issuer function may be tempting to misuse even by experienced
developers. There is a notion that the issuer certificate will always be
used in the final certification path, but it's just not always true.
Trying to make security decisions based on the results of this function is
a trap, so let's document that.
It turns out that old versions of glib-networking actually reordered the
certificate chain to match the final verification path. This no longer
happens since a long time ago, because it was a buggy mess. Instead, we
rely on the TLS library to build the final verification path. Their path
building is not very good, but at least it's consistent. The point of
these doc updates is to clarify that only the TLS library can make
security decisions.
Document that HTTP requests may be performed to look up missing
certificates.
Finally, let's document that certificate verification using GTlsDatabase
cannot be as smart as certificate verification performed directly by
GTlsConnection.
g_win32_package_parser_enum_packages() reads beyond the end of a buffer
when doing a memcpy. With app verifier enabled on Windows, it causes
the application to crash on startup.
This change limits the memcpy to the size of the source string.
Fixes: #2454
This reverts commit 7aa0580cc5.
As stated in #2316, that commit was a workaround to allow gnome-keyring
and msmtp to continue to get their session bus address from
`DBUS_SESSION_BUS_ADDRESS`, even though they’re `AT_SECURE`. The timeout
on that workaround has expired so that commit is now being reverted.
Fixes: #2316
You need to separate the first entry in the list from the preceding
paragraph, and you should add a space before the enumerating symbol.
GTK-Doc accepts a very lax Markdown syntax, but any other tool parsing
our documentation will likely fail.
The value should be initialized to NULL before calling
g_win32_registry_key_get_value_w(), to ensure that cleanup
can be done unconditionally afterward.
To ensure that the watch is properly re-set every time, call
watch_keys() from the watch callback. Previously the watch was only
renewed after a data update was done in a worker thread, which made
no sense, since the update function was implemented in such a way
that it can (and should) be re-triggered on each key change, until
the changes stop coming, and that can only happen if we renew
the registry watcher right away.
If a key watch is renewed from the key watch callback, it results
in the callback being NULL, since we clear it after we call it.
Rearrange the function to make sure that the changes done by the
callback function are preserved properly.
This function can, in fact, return STATUS_SUCCESS. We shouldn't
assert that it doesn't.
For now interpret it just like STATUS_PENDING (i.e. APC will be called),
see how it goes (it isn't documented how the function behaves in this
case, we have to play it by ear).
Note that while we *can* use a better-documented RegNotifyChangeKeyValue() here,
it communicates back to us via event objects, which means that the registry
watcher would have to interact with the main loop directly and insert its
events (plural; one event per key) there. That would make the API more complicated.
Whereas the internal NT function communicates by calling an APC - we're good
as long as something somewhere puts the thread in alertable state.
