Not everything should be an int. This code is quite dated. We now try to
use `guint8*` to represent arbitrary binary data, rather than `guchar*`
(which makes it sound like some form of string).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While it’s not a supported public part of the API, exporting this
symbol from the library means we can easily test the DNS record parser,
which is important to do since it handles untrusted data from the
network.
This tests for #2503. It's fragile, but there is no non-fragile way to
test this. If the test breaks in the future, it will pass without
successfully testing the bug, not fail spuriously, so I think this is
OK.
We should run test_pass_fd twice, once using gspawn's fork/exec codepath
and once attempting to use its posix_spawn() codepath. There's no
guarantee we'll actually get the posix_spawn() codepath, but it works
for now on Linux.
For good measure, run it a third time with no flags at all.
This causes the test to fail if I separately break the fd remapping
implementation. Without this, we fail to test fd remapping on the
posix_spawn() codepath.
Specs say that on Unix id should be desktop file id from the xdg menu
specification, however, currently code just uses basename of .desktop file.
Fix that by finding the .desktop file in all the desktop_file_dirs and use
basename only as a fallback.
See https://specifications.freedesktop.org/menu-spec/latest/go01.html#term-desktop-file-id
and https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s02.html#desktop-file-id
"To determine the ID of a desktop file, make its full path relative to the
$XDG_DATA_DIRS component in which the desktop file is installed, remove the
"applications/" prefix, and turn '/' into '-'."
Also, add unit test that verifies Desktop Id is being correctly set
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
This is sad, but GResolver has one member variable for historical
reasons, to implement the reload signal. Since it offers a global
singleton, we should make sure it's really safe to use from multiple
threads at once.
This call was needed once upon a time, when GResolver had subclasses
that presumably relied on this. Nowadays, we have only
GThreadedResolver, which does not need it. res_init() is dangerous
because it modifies global state, so let's get rid of it.
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)
^~
