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>
