Glib cannot be built statically on Windows because glib, gobject and gio
modules need to perform specific initialization when DLL are loaded and
cleanup when unloaded. Those initializations and cleanups are performed
using the DllMain function which is not called with static builds.
Issue is known for a while and solutions were already proposed but never
merged (see: https://gitlab.gnome.org/GNOME/glib/-/issues/692). Last
patch is from version 2.36.x and since then the
"constructor/destructor" mechanism has been implemented and used in
other part of the system.
This patch takes back the old idea and updates it to the last version of
glib to allow static compilation on Windows.
WARNING: because DllMain doesn't exist anymore in static compilation
mode, there is no easy way of knowing when a Windows thread finishes.
This patch implements a workaround for glib threads created by calling
g_thread_new(), so all glib threads created through glib API will behave
exactly the same way in static and dynamic compilation modes.
Unfortunately, Windows threads created by using CreateThread() or
_beginthread/ex() will not work with glib TLS functions. If users need
absolutely to use a thread NOT created with glib API under Windows and
in static compilation mode, they should not use glib functions within
their thread or they may encounter memory leaks when the thread finishes.
This should not be an issue as users should use exclusively the glib API
to manipulate threads in order to be cross-platform compatible and this
would be very unlikely and cumbersome that they may mix up Windows native
threads API with glib one.
Closes#692
The gdbus-codegen tool generates documentation from the XML introspection
description of a D-Bus interface. Currently, only DocBook is supported at
the moment, but not every modern documentation generator can handle that
format. The reStructuredText format is a bit more well-supported,
especially in documentation generators for non-C languages.
Unlike DocBook, we get to make our own structure and conventions for how
we structure the documentation when using reStructuredText.
When parsing a comment we're adding <para> elements ourselves, but the
DocBook generator already wraps any block of text that does not start
with a <para> element with one.
xucred does not provide the peer pid id, but this can be fetched
from the socket LOCAL_PEERPID option. Note that we only support
it when creating the credentials from a local socket, if
the credential comes from a message over a socket the peer
pid id will not be set and -1 will be returned when trying
to get the pid for the credential.
D-Bus reference implementation doesn't require more than the claimed
process SID as part of the AUTH initial data for EXTERNAL.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The code is based from #1351 patch and existing similar code in
gdbusprivate.c. The next commit will replace that existing code with
those helpers.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This commit puts an additional underscore before the external symbol
`_g_binary_test1_resource_data` when using gcc for Windows, to match
the compiler's expectation.
Fixes#2571
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Using ld_flags would work, but that does not propagate ldflags to users
of glib. Meson's dependency() call will propagate apple framework
dependencies to downstream users.
Not everything should be an int. This code is quite dated. We now try to
use `guint8*` to represent arbitrary binary data, rather than `guchar*`
(which makes it sound like some form of string).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While it’s not a supported public part of the API, exporting this
symbol from the library means we can easily test the DNS record parser,
which is important to do since it handles untrusted data from the
network.
This tests for #2503. It's fragile, but there is no non-fragile way to
test this. If the test breaks in the future, it will pass without
successfully testing the bug, not fail spuriously, so I think this is
OK.
We should run test_pass_fd twice, once using gspawn's fork/exec codepath
and once attempting to use its posix_spawn() codepath. There's no
guarantee we'll actually get the posix_spawn() codepath, but it works
for now on Linux.
For good measure, run it a third time with no flags at all.
This causes the test to fail if I separately break the fd remapping
implementation. Without this, we fail to test fd remapping on the
posix_spawn() codepath.
Specs say that on Unix id should be desktop file id from the xdg menu
specification, however, currently code just uses basename of .desktop file.
Fix that by finding the .desktop file in all the desktop_file_dirs and use
basename only as a fallback.
See https://specifications.freedesktop.org/menu-spec/latest/go01.html#term-desktop-file-id
and https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s02.html#desktop-file-id
"To determine the ID of a desktop file, make its full path relative to the
$XDG_DATA_DIRS component in which the desktop file is installed, remove the
"applications/" prefix, and turn '/' into '-'."
Also, add unit test that verifies Desktop Id is being correctly set
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
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.
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.
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>
gio/tests/gio-du.c: In function 'main':
gio/tests/gio-du.c:74:11: error: parameter 'argc' set but not used
74 | main (int argc, char **argv)
| ~~~~^~~~
gio/ginputstream.c: In function 'g_input_stream_real_skip':
gio/ginputstream.c:433:31: error: comparison of integer expressions of different signedness: 'goffset' {aka 'long long int'} and 'long long unsigned int'
433 | (start + count) > (guint64) end)
| ^
gio/gwin32appinfo.c: In function 'uwp_package_cb':
gio/gwin32appinfo.c:3383:17: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i = 0; i < supported_extgroups->len; i++)
^
gio/gwin32appinfo.c:3389:29: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_ext = 0; i_ext < grp->extensions->len; i_ext++)
^
gio/gwin32appinfo.c:3430:35: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_verb = 0; i_verb < grp->verbs->len; i_verb++)
^
gio/gwin32appinfo.c:3463:33: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_hverb = 0; i_hverb < ext->verbs->len; i_hverb++)
^
gio/gwin32appinfo.c:3478:17: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i = 0; i < supported_protocols->len; i++)
^
gio/gwin32appinfo.c:3541:33: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_hverb = 0; i_hverb < url->verbs->len; i_hverb++)
^
gio/gwin32appinfo.c: In function 'g_win32_app_info_launch_internal':
gio/gwin32appinfo.c:4799:37: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (p_index = 0; p_index <= g_strv_length (envp); p_index++)
^~
gio/gwin32packageparser.c: In function 'WIN32_FROM_HRESULT':
gio/gwin32packageparser.c:99:30: warning: comparison of integer expressions of different signedness: 'long unsigned int' and 'long int'
if ((hresult & 0xFFFF0000) == MAKE_HRESULT (SEVERITY_ERROR, FACILITY_WIN32, 0) ||
^~
This was previously done (by commit 63038d1e4c) in one of the cases
where `kill_test_service()` was called — but not the other.
This meant that one instance of `gdbus-testserver` could still be
around when (as it happens, due to the order of the tests) the
`/gdbus/proxy/no-match-rule` test was run. It would start a second
instance of `gdbus-testserver`, which would exit early due to the test
name still being owned on the bus. The first (killed) instance of
`gdbus-testserver` would then exit, leaving no test servers running, and
hence the new test would fail.
This was being seen as frequent CI failures, particularly on FreeBSD
(must have slightly different timing for process signalling and
termination from Linux).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Once upon a time, we tried to return all possible certificate errors,
but it never actually worked reliably and nowadays we have given up.
This needs to be documented because a reasonable developer would not
expect it.
Because mistakes could be security-critical, I decided to copy the same
warning in several different places rather than relying only on
cross-referencese.
These are known leaks, as they were being done in tests which were
checking precondition failures.
However, since we know what happens when the failures occur, we can
still free the input data reliably, so do that.
This improves the valgrind output for `actions` to show zero definite
leaks.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The `actions` test previously waited an arbitrary 100ms for various
D-Bus messages to be sent/received, before checking the results of those
messages.
Normally, this would work, but on heavily loaded CI systems, it would
sometimes fail. For example,
https://gitlab.gnome.org/GNOME/glib/-/jobs/1611701.
Fix that by waiting for the condition being checked to evaluate to true,
rather than waiting an arbitrary period of time. On faster machines,
this will speed the tests up too.
Assume that the global default `GMainContext` is in use, so a
`GMainContext*` pointer doesn’t have to be passed around.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
gio/gcontenttype-win32.c: In function 'get_registry_classes_key':
gio/gcontenttype-win32.c:66:78: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'int'
if (ExpandEnvironmentStringsW (wc_temp, wc_temp_expanded, len) == len)
^~
This allows the flag to allow interactive auth to be set. Previously, it
was unconditionally unset.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
D-Bus has an upper limit on number of Match rules and it's rather easy to hit
with a big number of proxies with signal subscriptions. This happens with
NetworkManager with hundreds of devices or connection settings. By passing
G_DBUS_SIGNAL_FLAGS_NO_MATCH_RULE to g_dbus_connection_signal_subscribe(), the
user can call AddMatch with a less granular match instead of a match per every
proxy.
Tests subsequently added by Philip Withnall.
Fixes: #1109
- Isolate the first meaningful paragraph, for gi-docgen's summary
- Describe get_object() as a binding API
- Fix reference to get_item() inside get_item_type()
g_check_setuid does more than setuid checks when using AT_SECURE.
Make sure that it is referenced in the error message to help
users debug in case or errors
Closes#2518
Fix another variant of the previous commit, this time specific to the
idle callback of a method call on a subtree object, racing with
unregistration of that subtree.
In this case, the `process_subtree_vtable_message_in_idle_cb()` idle
callback already has a pointer to the right `ExportedSubtree` struct,
but again doesn’t have a strong reference to it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
If `g_dbus_connection_unregister_object()` (or `unregister_subtree()`)
was called from one thread, while an idle callback for a method call (or
a property get or set) was being invoked in another, it was possible for
the two to race after the idle callback had checked that the
object/subtree was registered, but before it had finished dereferencing
all the data related to that object/subtree.
Unregistering the object/subtree would immediately free the data,
leading the idle callback to cause a use-after-free error.
Fix that by giving the idle callback a strong reference to the data from
inside the locked section where it checks whether the object/subtree is
still registered.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2400
This is needed for an upcoming change which decouples their lifecycle
from their presence in the `map_id_to_ei` and `map_id_to_es` hash
tables.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
Move it further up the file, but make no changes to it. This will help
with a subsequent commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
This introduces no functional changes; it only simplifies the code.
Instead of maintaining a separate pointer to the backend iff it’s a
`GDelayedSettingsBackend`, just test the `backend` pointer’s type.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2426
Previously, the delay-apply status of the parent `GSettings` object
would be partially inherited: `settings->priv->backend` in the child
`GSettings` object would point to a `GDelayedSettingsBackend`, but
`settings->priv->delayed` would be `NULL`.
The expectation from https://bugzilla.gnome.org/show_bug.cgi?id=720891
was that `get_child()` would fully inherit delay-apply status.
So, ensure that `settings->priv->delayed` is correctly set to point to
the delayed backend when constructing any `GSettings`. Update the tests
to work again (presumably the inverted test was an oversight in the
original changes).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2426
`g_settings_reset()` changes the value of the setting to `NULL`;
`add_to_tree()` was not handling that correctly.
Add a unit test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2426
