The action name, parameter and new state are all controlled by an
external process, so can’t be trusted. Ensure they are validated before
being passed to functions which assert that they are correctly typed and
extant.
Add unit tests.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Backport: cherry-picked to glib-2-74, and additional braces added to
avoid a `-Wdeclaration-after-statement` warning not present on `main`
because we’ve dropped that warning on `main`
Helps: #1904
Instead, iterate the `GMainContext` directly. This allows tests on
asynchronously returned values to be done in the actual test function,
rather than a callback, which should make the tests a little clearer.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This makes the code a little easier to understand and allows the kernel
a little bit more leeway in scheduling the callback, which is fine
because we don’t need high accuracy here.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`g_notification_backend_new_default()` adds a reference on
`backend->dbus_connection` (if non-`NULL`), but nothing ever unreffed
that.
Fix that by adding a dispose method.
In practice this is not really a problem, because the notification
backend is held alive by a `GApplication`, which lives as long as the
process. It’ll be a problem if someone is to ever add unit tests for
`GNotificationBackend`s though. So let’s fix it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The code is correct, but from a quick read-through it wasn’t entirely
clear to me how it handled floating `GVariant`s in object state or the
`parameter` argument.
Add an assertion and some comments to hopefully clarify things a little.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Further to commit bcd364afef984da894045, fix the types accepted by the
`g_str_equal()` macro for C++ too. C++ is more restrictive about
const-correctness.
Add unit tests.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2820
The new macro form of `g_str_equal()` had stricter type checking than
the original function form. That would be nice, except it causes new
compiler warnings in third party projects, which counts as an API break
for us, so unfortunately we can’t do it.
Add some tests to prevent regressions on this again.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2809
This further helps with the potential denial of service problem in
issue #2782 / oss-fuzz#49462 / oss-fuzz#20177.
Instead of allocating a new `GVariant` for each nesting level of
maybe-types, allocate a single `GVariant` and give it the fully-nested
maybe type as its type. This has to be done in serialised form.
This prevents attackers from triggering O(size of container × typedecl
depth) allocations.
This is a follow up to commit 3e313438f1900a620485ba88aad64c4e857f6ad1,
and includes a test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2782
oss-fuzz#20177
oss-fuzz#49462
Backport !3029 “Revert "Handling collision between standard i/o file descriptors and newly created ones" ” to glib-2-74
See merge request GNOME/glib!3039
Now that we know it's a bad idea to avoid the standard io fd range
when getting pipe fds for g_unix_open_pipe, we should test to make sure
we don't inadvertently try to do it again.
This commit adds that test.
g_unix_open_pipe tries to avoid the standard io fd range
when getting pipe fds. This turns out to be a bad idea because
certain buggy programs rely on it using that range.
This reverts commit d9ba6150909818beb05573f54f26232063492c5b
Closes: #2795Reopens: #16
In g_proxy_resolver_lookup_async() we have some error validation that
detects invalid URIs and directly returns an error, bypassing the
interface's lookup_async() function. This is great, but when the
interface's lookup_finish() function gets called later, it may assert
that the source tag of the GTask matches the interface's lookup_async()
function, which will not be the case.
As suggested by Philip, we need to check for this situation in
g_proxy_resolver_lookup_finish() and avoid calling into the interface
here if we did the same in g_proxy_resolver_lookup_async(). This can be
done by checking the source tag.
I added a few new tests to check the invalid URI "asdf" used in the
issue report. The final case, using async GProxyResolver directly,
checks for this bug.
Fixes#2799
It’s entirely possible that `g_file_read_link()` will return a relative
path. Mention that in the documentation, and include a short example of
how to make the path absolute for further computation.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The changes in 6265b2e6f70d6f0ec4d16adcdc5f7c53aecf0da4 to reject weird
`/etc/localtime` configurations where `/etc/localtime` links to another
symlink did not consider the case where the target of `/etc/localtime`
is a *relative* path. They only considered the case where the target is
absolute.
Relative paths are permissible in all symlinks. On my Fedora 36 system,
`/etc/localtime`’s target is `../usr/share/zoneinfo/Europe/London`.
Fix the check for toolbx by resolving relative paths before calling
`g_lstat()` on them.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
g_close() now is async-signal-safe, as long as we don't request a GError
and pass a valid file descriptor.
Update "gspawn.c" to drop its safe_close() function and use
g_close() instead.
g_close() does something useful. It is not trivial to get EINTR handling of
close() right, in a portable manner. g_close() abstracts this.
We should allow glib users to use the function even in async-signal-safe
contexts, at least if the user heeds the caveat about GError and take care
not to fail assertions.
Backport 2.74: Modified to drop documentation changes to g_close() which
document its new async-signal-safe guarantees. They are not public
guarantees until 2.76. Also modified to include moving the code to
ignore `EINTR` from commit d5dc7d266f2b8d0f7d.
When collecting varargs, ignore the NOCOPY_CONTENTS
flag for variants. That is what our docs advice for
refcounted types, and it fixes a regression that
was inadvertendly introduced when we stopped doing
some extra GValue copies.
Includes a test case by Philip Withnall.
Fixes: #2774
This reverts commit 0ffe86a1f7e215e4561c3b9f1d03c3cd638ed00f.
This was intended to land for the 2.75.x unstable series, and not in the
2.74.x stable series.
Fixes: #2788
This reverts commit dd1f4f709ea8cad1a1d6184ee0883be128fb81d8.
which caused a regression on big-endian architectures (all doubles would
hash to zero).
Partially resolves#2787
Signed-off-by: Simon McVittie <smcv@collabora.com>
This reverts commit c1af4b2b886bd77d6d8857cf3f677edbc0d34a61,
which caused a regression on big-endian architectures (all 64-bit
integers would hash to zero).
Partially resolves#2787
Signed-off-by: Simon McVittie <smcv@collabora.com>
This reverts commit e02db8ea22d545749ecaf3be9d342cc565bc143a.
We can't guarantee a lack of hash collisions if we go back to the 2.74.0
hashing implementation.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Retry on EINTR is wrong on many OS, including Linux. See the comment
in g_close() why that is.
As we cannot use g_close() after fork, we had safe_close(). This had the
wrong retry loop on EINTR. Drop that.
This was especially problematic since commit 6f46294227f8 ('gspawn: Don’t
use g_close() in async-signal-safe context'). Before, safe_close() was
only called after fork, where there is only one thread and there is no
concern about a race.
This patch only exists for easier backporting of the bugfix. The code
will be reworked further next.
Fixes: 6f46294227f8 ('gspawn: Don’t use g_close() in async-signal-safe context')
