It must only be defined when building libgio. This requires some
workaround to allow include of some gio private headers.
When GIO_COMPILATION is not defined we cannot include individual gio
headers. We workaround that by defining __GIO_GIO_H_INSIDE__ in some
places. Also gdbusprivate.h is not an installed header, so it's fine to
include it directly.
There is currently no `dllimport` attribute on any of our function,
which prevents MSVC to optimize function calls.
To fix that issue, we need to redeclare all our visibility macros for
each of our libraries, because when compiling e.g. GIO code, we need
dllimport in GLIB headers and dllexport in GIO headers. That means they
cannot use the same GLIB_AVAILABLE_* macro.
Since that's a lot of boilerplate to copy/paste after each version bump,
this MR generate all those macros using a python script.
Also simplify the meson side by using `gnu_symbol_visibility : 'hidden'`
keyword argument instead of passing the cflag manually.
This leaves only API index to add manually into glib-docs.xml when
bumping GLib version. That file cannot be generated because Meson does
not allow passing a buit file to gnome.gtkdoc()'s main_xml kwarg
unfortunately.
Otherwise, the build will fail when the toolchain is static-only, even
with -Ddefault_library=static. I talked to a Meson developer in their
IRC channel, who told me that the correct fix was to ensure that
shared_library is only used if default_library != static.
Simulate launching applications using terminals by creating scripts on
the fly that are named as the terminals that we support, ensuring that
these are called with the arguments that we expect.
Related to: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2839
Check if thumbnails are created in the path we expect and that we can
retrieve their information, but also that we try to get the biggest size
available when multiple are available.
The GIconIface virtual functions were not introspectable as they use
complex parameters that GI isn't able to compute alone.
So provide introspection metadata to the two function pointers
definitions.
GIcon::from_tokens is a static virtual function so it won't actually
work until GI support for it [1] is merged.
[1] https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/361
In case we fail unlinking a file we could close again an FD that has
been already just closed. So avoid this by unsetting it when closing.
Coverity CID: #1474462
We've various macros definitions that are depending using C++ features
that may not work in all the standard versions, so recompile the cxx
tests that we have in all the ones we want to support.
desktop-app-info test may fail when repeated with multiple concurrent
processes because the actions test relies on checking the existence of
in the shared build directory, so by doing something like:
meson test -C _build desktop-app-info -t 0.3 --repeat 80
We may end up in timeout errors, because we are waiting for files that
have been already deleted by other processes.
To avoid this, let's rely on writing the files on `$G_TEST_TMPDIR` env
variable, that is always set and unique, given that we're using the
G_TEST_OPTION_ISOLATE_DIRS test option.
Those tools are not needed at runtime for typical applications,
distributions typically package them separately.
This makes `meson install --tag runtime` skip installation of those
tools. Omitting `--tag` argument will still install them, as well as
with `--tag bin,bin-devel`.
See https://mesonbuild.com/Installing.html#installation-tags.
The `(transfer none)` behaviour for `parameter_type` and `state_type`
parameters is implicit with the `const` attribute, but was incorrectly
determined to be `(transfer full)` in the GIR.
Add explicit `(transfer none)` annotations for these two parameters.
On our GDBus call callback wrapper we were completing the gdbus call but
ignoring the returned value, that was always leaked.
Fix this.
Helps with: https://gitlab.gnome.org/GNOME/glib/-/issues/333
When launching URIs via dbus we may ignore the callback if one was not
provided, however in such case we were also leaking the return value for
the gdbus call.
Unref it properly.
Helps with: https://gitlab.gnome.org/GNOME/glib/-/issues/333
When called with an empty URI list (or only inaccessible files),
g_document_portal_add_documents would not call g_variant_builder_end,
leaking the memory allocated by the variant builder.
Closes: https://gitlab.gnome.org/GNOME/glib/-/issues/2733
We were testing the case in which we were opening an actual file, and so
potentially using a fd-list, however we were missing the case in which a file
was not existent.
And in such case we are incidentally hitting a leak now.
The search_total_results address is always going to be non-zero, so the
check will always evaluate to true, and GCC is kind enough to point this
out to us.
The appropriate fix is checking if the size of the search results array
is larger than zero, and if so, copy them into the total results array.
As per commit a5390002 we're exiting with error in case fgets failed,
however it could also fail because of EOF (like on ^D), so in such case
we can just return early treating it as a non-error.
Otherwise still exit with error.
Fixes: #2737
* Remove an unneeded field from LaunchUrisData and add annotations
* Rename local GError* variables to local_error
* Use g_set_object
* Fix indentation
...of the application if many URI's are provided. This is important to note
because the GAppLaunchContext signals may be emitted multiple times during
a single launch operation.
We cannot cancel a spawn operation, but sometimes we have to
spawn the target application mutiple times (e.g. in case the
target app only supports one URI in its command-line, but we
were given multiple URI's), in that case continuously check
the cancellation status before attempting any spawn operation
First, there's no reason not to use the new `epoll_create1` system call,
which quickly obsoleted `epoll_create` which has an obsolete and
unused size argument.
But more specifically, it offers `EPOLL_CLOEXEC` which we want
to use for general hygeine - there's no reason to potentially
leak this file descriptor to forked processes.
(GLib itself carefully closes file descriptors when forking child
processes, but it may be linked with other software that doesn't;
notably in my case for example the Rust standard library does not
do this and hence relies more on the application code using
`O_CLOEXEC` and variants)
This is just a drive-by fix; I saw the system call when I was using
`strace` to debug something else in rpm-ostree.
This utility function will be called by both launch_uris and
launch_uris_async, passing a from_task parameter respectively
as NULL and non-NULL. The from_task parameter will be needed
to know whether GAppLaunchContext signals should be emitted
directly (from_task == NULL) or scheduled for emission on the
main thread (from_task != NULL).
All of these warnings indicate programmer error, so critical is most
appropriate here.
Exceptions: deprecation warnings are just warnings. Also, warnings that
are worded with uncertainty can remain warnings rather than criticals.
Using the Application Activation Manager coclass. Its threading model
is marked as 'both', so it can be instantiated in any apartment type
without marshaling.
gio tool has support for deleting attributes of the file. To delete attribute user
should specify type '--type="unset"'. This is not mentioned in help and therefore not
intuitive. By adding '-d' option, we make this process more obvious.
closes#2588
The prefix for GMarkupParseFlags enumeration members is G_MARKUP; this
means that G_MARKUP_PARSE_FLAGS_NONE gets split into
GLib.MarkupParseFlags.PARSE_FLAGS_NONE by the introspection scanner.
The `/*< nick=none >*/` trigraph attribute is a glib-mkenum thing, and
does not affect the introspection scanner; it would also only affect the
GEnumValue nickname, which is not used by language bindings to resolve
the name of the enumeration member. Plus, GMarkupParseFlags does not
have a corresponding GType anyway.
The prefix is G_TLS_CERTIFICATE, not G_TLS_CERTIFICATE_FLAGS. Having
G_TLS_CERTIFICATE_FLAGS_NONE leads to a FLAGS_NONE nick in the GType,
and a FLAGS_NONE member name in the introspection data.
Enumeration members should either have the name of the type as their
prefix, or they should all have the same prefix.
The "default flags" enumeration member for GApplicationFlags is
unfortunately named G_APPLICATION_FLAGS_NONE, while every other member
of the same type has a G_APPLICATION prefix. The result is that the nick
name of the enumeration member is "flags-none", and that language
bindings will have to use something like
Gio.ApplicationFlags.FLAGS_NONE.
To fix this API wart, we can deprecate the FLAGS_NONE member, and add a
new DEFAULT_FLAGS.
If stdout is the Journal but stderr is not, then we probably only want
to redirect stdout, or vice versa.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This prevents a launched process's output from being mixed up with the
output of the parent process, which can lead to the wrong program being
blamed for warning messages.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is an internal helper executable, which users shouldn't invoke
directly (see glib#1633).
When building for a single-architecture distribution, we can install
it as ${libexecdir}/gio-launch-desktop.
When building for a multiarch distribution, installing it into an
architecture-specific location and packaging it alongside the GLib
library avoids the problem discussed in glib#1633 where it would either
cause a circular dependency between the GLib library and a common
cross-architecture package (libglib2.0-bin in Debian), or require a
separate package just to contain gio-launch-desktop, or cause different
architectures' copies to overwrite each other.
Signed-off-by: Simon McVittie <smcv@collabora.com>
gio-launch-desktop was removed before checking GIO for potentially
unsafe environment variable references, so reverting its removal brought
this one back. If a setuid program is using GAppInfo then something is
probably already horribly wrong, but let's be careful anyway.
Signed-off-by: Simon McVittie <smcv@collabora.com>
A shell one-liner was enough to set GIO_LAUNCHED_DESKTOP_FILE_PID,
but ideally we also want to do the equivalent of sd_journal_stream_fd()
to set up its standard output and standard error streams.
Ideally we would call sd_journal_stream_fd() in a process that will
exec the real program, otherwise it will report the wrong process ID
in the Journal, but we can't easily do that in a forked child when
using posix_spawn() for subprocesses.
This reverts commit 2b533ca99a.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The dominant implementations of the well-known session and system
message buses are the reference implementation from the dbus project
(dbus-daemon) and the sd-bus-based reimplementation dbus-broker, both
of which have correct implementations for EXTERNAL authentication with
an unspecified authorization identity.
This makes it reasonably safe to assume that the well-known message
buses can cope with the unspecified authorization identity, even if we
cannot make the same assumption for custom servers such as the ones
used in ibus and gvfs (which might have been started with an older
GLib version before upgrading GLib in-place).
Signed-off-by: Simon McVittie <smcv@collabora.com>
When using a GDBus client in a non-trivial user namespace, the result of
geteuid() can differ from the uid in the namespace where the server is
running. This would result in connection attempts being rejected, because
the identity that the client claims to have does not match the identity
that the server derives from its credentials.
RFC 4422 allows us to send an empty authorization identity, which means we
want to authenticate as whatever identity the server can derive from our
out-of-band credentials. In particular, this resolves the authentication
failure when crossing between different Linux user namespaces.
Because D-Bus does not have a way to represent an empty initial response
as distinct from the absence of an initial response, we cannot use the
initial-response optimization (RFC 4422 §4.3.a) in this case, and must
fall back to waiting for the server to send a challenge.
Unfortunately, GDBus versions older than glib!2826 did not implement
the server side of this protocol correctly, and would respond to the
missing initial response in a way that breaks the SASL state machine
(expecting a response without sending a challenge), causing client and
server to deadlock with each waiting for the other to respond. Until
fixed versions of GDBus are widespread, we can't rely on having a server
that can cope with this, so gate it behind a flag, which can be set for
connections that are known to cross non-trivial namespace boundaries.
Originally inspired by
<1ed4723d38>,
and based on earlier work by Giuseppe Scrivano (in which the
cross-namespace behaviour was unconditional, rather than gated by a
flag).
Co-authored-by: Giuseppe Scrivano <giuseppe@scrivano.org>
Signed-off-by: Simon McVittie <smcv@collabora.com>
In Debian-style multiarch (libdir = lib/x86_64-linux-gnu or similar),
Red-Hat-style multilib (libdir = lib64 or lib) and Arch-style multilib
(libdir = lib or lib32), we have to run a separate version of
gio-querymodules to discover 32- or 64-bit modules on x86. Installing
modules in the directory used for each word size needs to trigger
recompilation of the correct modules list.
Debian, Fedora and Arch currently all have patches to facilitate this:
Debian moves gio-querymodules into ${libdir}/glib-2.0 and provides a
compat symlink in ${bindir}, while Fedora and Arch rename one or both
of the gio-querymodules executables to give it a -32 or -64 suffix.
We can avoid the need for these patches by making this a build option.
Doing this upstream has the advantage that the pkg-config metadata for
each architecture points to the correct executable and is in sync with
reality.
I'm using Debian's installation scheme with a separate directory here,
because the word-size suffix used in Fedora and Arch only works for the
common case of 32- and 64-bit multilib, and does not cover scenarios
where there can be more than one ABI with the same word size, such as
multiarch cross-compilation or alternative ABIs like x32.
Now that we have this infrastructure, it's also convenient to use it for
glib-compile-schemas. This works with /usr/share, so it only needs to
be run for one architecture (typically the system's primary
architecture), but using /usr/bin/glib-compile-schemas for the trigger
would result in either primary and secondary architectures trying to
overwrite each other's /usr/bin/glib-compile-schemas binaries, or a
circular dependency (the GLib library would have to depend on a
common package that contains glib-compile-schemas, but
glib-compile-schemas depends on the GLib library). Installing a
glib-compile-schemas binary in an architecture-specific location
alongside each GLib library bypasses this problem.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Instead of using a GDBusConnection, this does the handshake at a lower
level using specific strings in the SASL handshake, to verify that we
will interoperate with various clients including sd-bus, libdbus and
older versions of GDBus.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is an interoperability fix. The reference implementation of D-Bus
treats "DATA\r\n" as equivalent to "DATA \r\n", but sd-bus does not,
and only accepts the former.
Signed-off-by: Simon McVittie <smcv@collabora.com>
RFC 4422 appendix A defines the empty authorization identity to mean
the identity that the server associated with its authentication
credentials. In this case, this means whatever uid is in the
GCredentials object.
In particular, this means that clients in a different Linux user
namespace can authenticate against our server and will be authorized
as the version of their uid that is visible in the server's namespace,
even if the corresponding numeric uid returned by geteuid() in the
client's namespace was different. systemd's sd-bus has relied on this
since commit
1ed4723d38.
[Originally part of a larger commit; commit message added by smcv]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Sending an "initial response" along with the AUTH command is meant
to be an optional optimization, and clients are allowed to omit it.
We must reply with our initial challenge, which in the case of EXTERNAL
is an empty string: the client responds to that with the authorization
identity.
If we do not reply to the AUTH command, then the client will wait
forever for our reply, while we wait forever for the reply that we
expect the client to send, resulting in deadlock.
D-Bus does not have a way to distinguish between an empty initial
response and the absence of an initial response, so clients that want
to use an empty authorization identity, such as systed's sd-bus,
cannot use the initial-response optimization and will fail to connect
to a GDBusServer that does not have this change.
[Originally part of a larger commit; commit message added by smcv.]
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is an interoperability fix. If the line is exactly "DATA\r\n",
the reference implementation of D-Bus treats this as equivalent to
"DATA \r\n", meaning the data block consists of zero hex-encoded bytes.
In practice, D-Bus clients send empty data blocks as "DATA\r\n", and
in fact sd-bus only accepts that, rejecting "DATA \r\n".
[Originally part of a larger commit; commit message added by smcv]
Signed-off-by: Giuseppe Scrivano <giuseppe@scrivano.org>
Co-authored-by: Simon McVittie <smcv@collabora.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
This attribute will produce "deprecation" warnings when using it in
code that does not want dependencies on newer GLib versions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Using GMemorySettingsBackend before any other GSettingsBackend would
cause the following error: "Tried to implement non-registered extension
point gsettings-backend". This is due to a missing call to
_g_io_modules_ensure_extension_points_registered() in the GMemorySettingsBackend
type definition which registers the gsettings-backend extension point.
We don't need a cpp toolchain for building glib so lets just
automatically disable tests requiring one when not available.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
The test was flacky because we were only relying on the presence of a
file, while the callback could have not been called yet, while ensure
for both assumptions to be true before stop iterating the loop.
Fix a regression from commit abddb42d14, where it could pass `NULL` to
`g_task_get_cancellable()`, triggering a critical warning. This could
happen because the lifetime of `data->task` is not as long as the
lifetime of the `ConnectionAttempt`, but the code assumed it was.
Fix the problem by keeping a strong ref to that `GCancellable` around
until the `ConnectionAttempt` is finished being destroyed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2687
These headers have all been written manually, by looking through the git
log for each file and noting the copyright of each significant
contribution.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
While `gio_xdgmime` is unlocked, the data which `type` points to in the
xdgmime cache might get invalidated, leaving `type` as a dangling
pointer. That would not bode well for the `g_strdup (type)` call to
insert a new entry into the `type_comment_cache` once `gio_xdgmime` is
re-acquired.
This was spotted using static analysis, and the symptoms have not
knowingly been seen in the wild.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1474702
This will catch buggy implementations of GProxyResolver before they are
able to return bogus results to higher level code. In particular, if
g_proxy_resolver_lookup() returns NULL, it'd better set an error to
explain why.
It doesn't make sense for a proxy resolver to return NULL without an
error on the first call. Whereas a DNS resolver would do this to
indicate that a query completed successfully but found no results, a
proxy resolver should return "direct://" instead. Therefore, if we are
going to return NULL, we ought to have an error as well. Let's make sure
this actually happens by adding some fallback errors just in case
GProxyResolver feeds us weird results.
Additionally, we should not return any errors except
G_IO_ERROR_CANCELLED after the very first iteration. This is an API
contract of GSocketAddressEnumerator. Let's add some checks to ensure
this.
Note that we have inadequate test coverage for GProxyAddressEnumerator.
It's tested here only via GSocketClient. We could do a bit better by
testing it directly as well. For example, I've added tests to see what
happens when GProxyResolver returns both a valid and an invalid URI, but
it's not so interesting here because GSocketClient always uses the valid
result and ignores the error from GProxyAddressEnumerator.
Fixes#2597
This has no practical impact, since it's only a test, and none of the
test code would have hit this bug, but the GTestProxyResolver's check to
see if the URI scheme is simple:// currently only compares the first
four bytes of the string, so it's actually only checking for the "simp"
and would match anything else after that, e.g. "simpleton://". This is
surely not intended.
This was causing intermittent failures on macOS, depending on whether
the tmpdir ended with a `/` or `/some-dir`. `g_strrstr()` is not the
right function to use to extract a basename from a path, for this
reason.
When it failed, the macOS test was failing with:
```
ok 16 /gsubprocess/env
Bail out! GLib-GIO:ERROR:../gio/tests/gsubprocess.c:1507:test_cwd: assertion failed (basename == tmp_lineend_basename): ("/T\n" == "/\n")
```
The test now passes reliably, which means that it can be removed from
the list of expected failures on macOS.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
Creating a `GAppInfo` from a commandline isn’t currently supported on
macOS, but the implementation was incorrectly returning `NULL` without
setting the `GError`.
This was being caught by the new tests in `gio/tests/file.c`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
On macOS the comparison was failing as one of the paths had a trailing
slash while the other didn’t.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We used to do get and set atomic operations pair, but these may be
unsafe in some cases as threads may rely on data that is changed in
in between them, however this is not a problem if we do exchange the
pointers.
So just use exchange ops, in this way we can avoid lock/unlock mutex
dances
This makes calls to g_signal_connect_data() and g_signal_connect_object()
with default flags more self-documenting.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Despite the name, the call was still doing blocking operations when
looking for app handlers via GAppInfo. Now it's possible to use fully
async calls.
Together with previous commit, the API is now fully async.
Despite the name, we still used blocking calls to get the default app
for URI, now that we have an async implementation of the API to get the
default implementation for URI scheme, we can remove the blocking calls.
We did not check whether this function worked before, so add a simple
test case for it, providing some test functions to make it possible to
reply the same behavior
In some cases (such as in our CI tests) we may not have any dbus session
set after launching, but we always assumed so.
In case we have not a session bus set, we only have to return early.
In both callbacks of g_file_query_default_handler_async() we were
actually using I/O blocking APIs making it not fully async.
Now that such API is provided, we can use it.
While it's possible to create a directory synchronously via
g_dir_make_tmp(), there's no such API that performs it asynchronously.
So implement it using GFile, using a thread to perform such task.
Avoid re defining cases for GIoErrorEnum when we already handle them
through GFileError, so remove code duplication and just rely on
g_file_error_from_errno() to compute the file error and then use
g_io_error_from_file_error() to get the possible IOError.
In case it's something not handled as GFileError, we can use the same
logic as before.
This is now a safe change to do as we have covered all the supported
cases in tests.
It seems this script has potentially never worked properly under Python
3. It’s supposed to list all the `_get_type()` functions it can find in
the GIO headers, but since the regex string passed to `re.search()` was
not a Python regex, nothing was matching.
Fix that, and do another few small cleanups to the script.
This makes the `defaultvalue` test not skip all the types.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When running under a strict TAP parser this was previously producing
problematic non-conforming output.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is unlikely to be a bug in practice, as the certificate pointed to
by `root` should have a ref held on it as the issuer of another
certificate in the chain.
However, we can’t guarantee that’s how the `GTlsCertificate`
implementation behaves, so keep a temporary ref on `root` until it’s no
longer needed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1489985
Rather than carrying the copylib around inside GLib, which is a pain to
synchronise and affects our code coverage statistics.
This requires updating the CI images to cache the new subproject,
including updating the `cache-subprojects.sh` script to pull in git
submodules.
It also requires adding `gioenumtypes_dep` to be added to the
dependencies list of `libgio`, since it needs to be build before GVDB as
it’s pulled in by the GIO headers which GVDB includes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2603
The interface was ready for this API but it was not provided.
So implement this, using a thread that calls the sync API for now.
Add tests.
Helps with: GNOME/glib#157
`GSocketClient` chains its internal `GCancellable` objects to ones
provided by the caller in two places using `g_cancellable_connect()`.
However, it never calls `g_cancellable_disconnect()`, instead relying
(incorrectly) on the `GCancellable` provided by the caller being
short-lived.
In the (valid) situation where a caller reuses one `GCancellable` for
multiple socket client calls, or for calls across multiple socket
clients, this will cause the internal `GCancellable` objects from those
`GSocketClient`s to accumulate, with one reference left each (which is
the reference from the `g_cancellable_connect()` closure).
These `GCancellable` instances aren’t technically leaked, as they will
all be freed when the caller’s `GCancellable` is disposed, but they are
no longer useful and there is no bound on the number of them which will
hang around.
For a program doing a lot of socket operations, this still-reachable
memory usage can become significant.
Fix the problem by adding paired `g_cancellable_disconnect()` calls.
It’s not possible to add a unit test as we can’t measure still-reachable
memory growth before the end of a unit test when everything has to be
freed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2670
Dynamically, these will only ever be used after they’ve been initialised
due to correct checking of `use_udp` throughout the test. However,
that’s a global variable and the static analyser is assuming it might
change value. So help it out by NULL-initialising the variables so they
can never be used uninitialised.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
