Improve the performance of canonicalising filenames with many `..` or
`.` components, by modifying the path inline rather than calling
`memmove()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2541
Added `g_alloca0()` which wraps `g_alloca()` and initializes
allocated memory to zeroes.
Added `g_newa0()` which wraps `g_alloca0()` in a typesafe manner.
Refreshed and tweaked by Nishal Kulkarni.
The charset set in `CHARSET` overrides the charset after the `.` in any
`LC_*` category (set via the environment or `setlocale()`). This will
break many tests, but in particular it definitely breaks the
`/GDateTime/format_mixed/` tests which are specifically checking
different charsets being set for different `LC_*` categories.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2514
Users should probably never be setting this — instead, just add the
charset after a `.` in `LANGUAGE`/`LC_ALL`/`LC_*`/`LANG`.
I can’t find any reference (in `git log`, code comments, or man pages)
to this environment variable being standardised or documented or even
used anywhere outside GLib. Perhaps it should eventually be removed.
If anybody finds references as to why GLib checks `CHARSET`, this
comment can be updated in future.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2514
De-duplicate g_nearest_pow() implementation and add some overflow protections to g_ptr_array_maybe_expand(), g_string_maybe_expand() and g_string_chunk_insert_len()
See merge request GNOME/glib!2368
If the new string's length plus the existing storage's length is
overflowing a gsize, we would previously memcpy() the string over the
bounds of the previous allocation.
Similarly if the string's size was bigger than G_MAXSIZE / 2 we would've
previously allocated 0 bytes.
Now instead create a new allocation that fits the string.
It might otherwise happen that the return value from g_nearest_pow()
does not fit into a guint, i.e. it might be G_MAXUINT + 1 if that fits
into a gsize.
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.
Currently `g_prgname` can be freed by `g_set_prgname()` while another
thread is holding a pointer to it.
We use GQuark when setting g_prgname so that string is never released once set.
Also added unit test, which checks if setting prgname in multi-threaded
program is safe.
Closes: #847
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.
`clang-format-11` is now what’s available in our Debian Stable CI image.
This should fix failures in the `style-check-diff` job.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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
