Libgirepository is not GLib, and it should not use GLIB_DEPRECATED,
GLIB_DEPRECATED_FOR, and GLIB_UNAVAILABLE macros (as the GLib
documentation clearly states).
When using them, we don't get the proper macro expansion, so deprecated
symbols suddenly disappear from our shared library.
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.
Commit 6bab939bf ("girffi.c: fix return value for g_callable_info_prepare_closure()")
effectively changes semantics of return value from code pointer to data pinter (closure).
`gjs` (and probably other software) relies on old (incorrect) semantics of
g_callable_info_prepare_closure(): https://gitlab.gnome.org/GNOME/gjs/-/issues/428
This change exposes the API that allows extracting directly
callacble code pointer. `gjs` will have to adapt to the new API.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
The initial failure was observed on `meld` against recently released
`libffi-3.4-rc1`. There `meld` crashes as:
```
$ meld
Segmentation fault (core dumped)
$ gdb --args /usr/bin/python3.9 /usr/bin/meld
(gdb) run
...
Thread 1 "python3.9" received signal SIGSEGV, Segmentation fault.
0x00007fffe9ac1ae8 in g_callable_info_free_closure (
callable_info=0x555555d45990, closure=0x7fffe9e70c20)
at ../gobject-introspection-1.68.0/girepository/girffi.c:428
428 g_free (wrapper->ffi_closure.cif->arg_types);
(gdb) bt
callable_info=0x555555d45990, closure=0x7fffe9e70c20)
at ../gobject-introspection-1.68.0/girepository/girffi.c:428
data=0x555555d252d0)
at ../pygobject-3.40.1/gi/pygi-closure.c:635
...
```
The bug here is in type mismatch between expected return value of
`g_callable_info_prepare_closure()` and actual value (executable
code pointer):
```c
ffi_closure * g_callable_info_prepare_closure(...) {
gpointer exec_ptr;
...
status = ffi_prep_closure_loc (&closure->ffi_closure, cif, callback, user_data, exec_ptr);
return exec_ptr;
}
```
Note: `exec_ptr` is a code pointer that could be directly executed by
caller, like `((rt (*)(a1,a2))exec_ptr)(1,2);` It should never be wrapped
into an `ffi_closure*`, which is normally called via `ffi_call(closure, ...)`.
We see the problem when we try to free direct code pointer instead of
`ffi_closure()` as starting from libffi-3.4 executable trampoline and
`ffi_closure()` don't necessarily live in the same block:
9ba559217b
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
`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
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>
