It warns that configured files must be referred to by reference rather
than by name, and that support for the latter will be dropped with Meson
2.0.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Feature test macros always need to be defined before any headers are
included. This triggers a redefinition warning with GCC 16 and the new
gnu11 C level.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
In the backport commit 4235f7b42 a new string was accidentally added
which broke string freeze. Because it’s very unlikely this string will
be shown (it’s an error message only shown if running a custom D-Bus
server and it’s being attacked by a malicious client), just drop the
translation marker on this stable branch.
The string will get translated for the next stable release on `main`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: https://gitlab.gnome.org/Teams/Translation/Coordination/-/work_items/529
The client isn’t trusted at this point, and there was previously nothing
limiting how long a line `GDBusAuth` would read. So an untrusted client
could exhaust the server’s memory by sending anything except `\r\n`.
Fix that by applying a reasonably length limit when reading a line, and
add a unit test.
Spotted by Gitee Codepecker Lab.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3985
g_type_check_is_value_type and g_type_test_flags both read global memory,
so can't be const. They only seem to write for the purpose of a lock, which
they undo at the end, so maybe we can get away with G_GNUC_PURE here.
Bug: https://gitlab.gnome.org/GNOME/glib/-/work_items/3984
Signed-off-by: Sam James <sam@gentoo.org>
g_type_ensure has a large comment saying _get_type shouldn't be
marked with G_GNUC_CONST because it has side-effects on the first
run, but it's OK if you consistently call g_type_ensure first.
Unfortunately, this isn't accurate. GCC trunk (observed at r17-1725-ge259a182e1f100)
now analyses points-to information more effectively and propagates its
findings, so it sees the function modifies some global state, concludes
that can't be possible (because of the const attribute), and deletes
the stores.
pure unfortunately is unsuitable for *_get_type too as it has a side-effect
(writes to global memory).
Mesa had a similar issue which I fixed recently [0]. glib and glibmm likely
want the (not-yet-implemented) 'idempotent' attribute instead [1]. In fact,
this exact problem is what motivated that request! :)
ebassi mentions an alternative to the current setup as well, using
atomics [2].
This problem has gone back many years but the compiler has finally
fully outsmarted us here, so give in.
[0] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42361
[1] https://gcc.gnu.org/PR32911
[2] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4249#note_2583110
Fixes: https://gitlab.gnome.org/GNOME/glib/-/work_items/3984
Signed-off-by: Sam James <sam@gentoo.org>
Commit ebbeb318 "gvariant: Tweak GVariantIter heap allocation size"
changed the code path that allocates iterators on the heap to use
the full size of the public iterator struct (including padding),
but didn't change the matching g_slice_free() call. g_slice_free() is
implemented as basically g_free_sized(), so the size passed to it
should match the size that was allocated.
Fixes: ebbeb318 "gvariant: Tweak GVariantIter heap allocation size"
Signed-off-by: Simon McVittie <smcv@collabora.com>
This re-works commit 608b846f38, because
it didn’t actually fix the warning on msys2-clang64.
Rather than go through contortions to try and squash that warning, just
allocate the full size struct instead. If people are worried about the
allocation size here, they really should already be using a stack
allocated GVariantIter instead.
Fixes CI failure https://gitlab.gnome.org/GNOME/glib/-/jobs/6444549.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
For reasons unknown to me, the public `GVariantIter` struct is declared
as being 16 pointers in size, but the private internal implementation of
it, `struct heap_iter`, is smaller (10 pointers).
Internally, the `GVariantIter` code casts iters around between
`GVariantIter`, `struct heap_iter` and `struct stack_iter` (which is
smaller still) quite merrily — presumably with appropriate magic checks
in place because we’ve never had a bug report about it.
However, allocating `struct heap_iter` (10 pointers) and immediately
casting it to `GVariantIter` (16 pointers) is now triggering a new
`-Walloc-size` warning in clang 22, which is fair enough.
Because C is serious about type safety, let’s go through some
contortions to squash that warning while continuing to do weird and
inadvisable things.
Diagnosed by Luca Bacci in
https://gitlab.gnome.org/GNOME/glib/-/issues/3922#note_2722553; fixes CI
failure https://gitlab.gnome.org/GNOME/glib/-/jobs/6360619:
```
FAILED: [code=1] glib/libglib-2.0-0.dll.p/gvariant.c.obj
"C:\msys64\clang64\bin/ccache.EXE" "cc" "-Iglib/libglib-2.0-0.dll.p" "-Iglib" "-I../glib" "-I." "-I.." "-fvisibility=hidden" "-fdiagnostics-color=always" "-D_FILE_OFFSET_BITS=64" "-Wall" "-Winvalid-pch" "-Wextra" "-Wpedantic" "-Werror" "-std=gnu99" "-O0" "-g" "-D_GNU_SOURCE" "-DUNICODE" "-D_UNICODE" "-fno-strict-aliasing" "-DG_ENABLE_DEBUG" "-Wfloat-conversion" "-Wimplicit-fallthrough" "-Wmisleading-indentation" "-Wmissing-field-initializers" "-Wnonnull" "-Wnull-dereference" "-Wunused" "-Wno-unused-parameter" "-Wno-cast-function-type" "-Wno-pedantic" "-Wno-format-zero-length" "-Wno-variadic-macros" "-Werror=format=2" "-Werror=init-self" "-Werror=missing-include-dirs" "-Werror=pointer-arith" "-Werror=unused-result" "-Wstrict-prototypes" "-Wno-bad-function-cast" "-Werror=implicit-function-declaration" "-Werror=missing-prototypes" "-Werror=pointer-sign" "-Wno-string-plus-int" "-Wno-typedef-redefinition" "-mms-bitfields" "-DG_LOG_DOMAIN=\"GLib\"" "-DGLIB_COMPILATION" "-DPCRE2_STATIC" -MD -MQ glib/libglib-2.0-0.dll.p/gvariant.c.obj -MF "glib/libglib-2.0-0.dll.p/gvariant.c.obj.d" -o glib/libglib-2.0-0.dll.p/gvariant.c.obj "-c" ../glib/gvariant.c
../glib/gvariant.c:2992:27: error: allocation of insufficient size '80' for type 'GVariantIter' (aka 'struct _GVariantIter') with size '128' [-Werror,-Walloc-size]
2992 | iter = (GVariantIter *) g_slice_new (struct heap_iter);
| ^
../glib/gslice.h:56:33: note: expanded from macro 'g_slice_new'
56 | #define g_slice_new(type) ((type*) g_slice_alloc (g_slice_alloc_size (type)))
| ^
1 error generated.
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
...and thus for generating coverage data, GIR data, and docs.
At the same time we set msys2-mingw32 as weekly-schedule or
manual.
MSYS2 has deprecated the MINGW32 environment since quite some:
https://www.msys2.org/news/#2023-12-13-starting-to-drop-some-32-bit-packages
(Backport 2.88: Minor cherry pick conflict fixes in
supported-platforms.md)
The following error has just popped up in mingw32 CI, which presumably
means the compiler has just been upgraded under our feet again:
```
../glib/gnulib/vasnprintf.c: In function '_g_gnulib_vasnprintf':
../glib/gnulib/vasnprintf.c:2429:21: error: variable 'flags' set but not used [-Werror=unused-but-set-variable=]
2429 | int flags = dp->flags;
| ^~~~~
cc1.exe: all warnings being treated as errors
```
This highlighted a bug in the version of gnulib we’re using, where the
`flags` variable was assigned but never used.
In lieu of updating our gnulib copylib version (which I don’t have the
energy to do right now; see #2603), copy across the fix for this issue
from upstream.
It’s upstream commit 5527d5c548702b89d217bbe58036996066a709b6.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
We can do this because `gdbusauthmechanism.h` is a private header.
Hook it up to the existing `reject_reason` code in each
`GDBusAuthMechanism` implementation, as all three implementations
currently intermingle reject reasons from the server and client code, so
there would currently be no benefit to having a separate server and
client implementation of `*_get_reject_reason()`.
This new private API will be used in a new unit test in the following
commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The D-Bus specification says the cookie ID has to be non-negative, but
we weren’t checking that (or checking that it was non-empty).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Without validation, the server could send a malicious context which
contains path traversal characters, allowing it to exfiltrate a SHA-1
hashed copy of arbitrary data from the client’s file system.
To exploit this successfully would require the client to choose to
connect peer-to-peer to a malicious D-Bus server and to choose the SHA-1
authentication mechanism in preference to all the other mechanisms. This
is vanishingly unlikely.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3931
This fixes the addition happening with type `uint32_t`, rather than the
expected `gssize`. Because of the narrower type, this could have
resulted in integer overflow for large header lengths, bypassing the
message length check lower down in the function.
This is not exploitable in practice unless communicating peer-to-peer
with a malicious D-Bus peer, as invalid messages like this would be
filtered out by the message bus (such as `dbus-daemon`).
Rework the arithmetic to use checked arithmetic functions into a
`size_t` (largely as suggested by Simon McVittie), and add some unit
tests. Simply doing the arithmetic in the `gssize` domain would not fix
the issue on 32-bit systems.
Based on a report by Koda Reef, albeit reverse engineered as the report
did not contain a proof of concept of the vulnerability.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3933
If this method was called on a key file key which has an empty value,
`len == 0` and this leads to a one-byte under-read off the start of the
key file buffer.
Spotted by linhlhq as #YWH-PGM9867-200. The suggested fix is theirs, and
the unit test is adapted from their report. I added the fuzzing test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3930
If the line terminator is longer than a single byte, and the current
line extends to the end of the buffer, and the buffer (which is a
`GString`) is near a power of two in length (as that’s how `GString`s
are allocated) it’s possible for the `memcmp()` which checks the
terminator to read off the end of the string buffer.
Fix that by checking the terminator length against the last character
before calling `memcmp()`. Add a unit test.
Spotted by linhlhq as #YWH-PGM9867-199. The fix is theirs (validated by
me), and the unit test is adapted from their proof of concept.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3925
