Commits on Source (18)
-
We create an array that we never free, ensure this is the case. The previous commit gives CI a chance to check this with valgrind job. Found as part of another review: - https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2839#note_1524922
efb43ef8 -
Marco Trevisan authored
Backport !3008 “gio/gdesktopappinfo: Free the wrapped argv array on launch failure” to glib-2-74 See merge request GNOME/glib!3017
a1151bc1 -
Nart Tlisha authored681980d3
-
This wouldn't have caused an issue with the current header contents, but could have triggered a future bug.
1304f9ed -
Simon McVittie authored
Backport !3035 “portal: Fix broken header guard” to glib-2-74 See merge request GNOME/glib!3038
05fdb2d0 -
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
299812d5 -
Michael Catanzaro authored
Backport !3045 “gproxyresolver: lookup_finish() should better parallel lookup_async()” to glib-2-74 See merge request GNOME/glib!3046
6870d08d -
Ray Strode authored
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 d9ba6150 Closes: #2795 Reopens: #16
2a36bb4b -
Ray Strode authored
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.
1c1c452f -
Ray Strode authored
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
fcdf5ebd -
Nathan Follens authored5ee59004
-
Philip Withnall authored
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 3e313438 , and includes a test. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Fixes: #2782 oss-fuzz#20177 oss-fuzz#49462
64c2f5f3 -
Мирослав Николић authored25df8885
-
Philip Withnall authored
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
b46ed37c -
Marco Trevisan authored
Backport !3082 “gstrfuncs: Fix regression in types accepted by g_str_equal()” to glib-2-74 See merge request GNOME/glib!3084
c7aa6e3b -
Emmanuele Bassi authored
Backport !3061 “gvariant-parser: Speed up maybe_wrapper() by an order of magnitude” to glib-2-74 See merge request GNOME/glib!3063
79085320 -
Philip Withnall authored
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
-
Simon McVittie authored89e29193
This diff is collapsed.
This diff is collapsed.