This localizes knowledge of the internal structure of
$XDG_RUNTIME_DIR/.flatpak into the flatpak-instance module.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Running Flatpak Chromium on NixOS fails with the following error:
> Error calling Spawn(): org.freedesktop.DBus.Error.FileNotFound: Failed to start command: Failed to execute child process “flatpak” (No such file or directory)
Presumably, Chromium calls portal’s `Spawn` method with `FLATPAK_SPAWN_FLAGS_CLEAR_ENV` flag, which also removes `PATH`.
Since NixOS does not install programs to global `/usr/bin` and relies solely on `PATH`, this is probably what prevents `flatpak` command itself from being found.
There is a relevant TODO note in the code about `LD_LIBRARY_PATH` but at least for `PATH`, we can solve the issue by hardcoding the path to the binary.
This is a step towards being able to build Flatpak using Meson, which
is becoming widely available even in LTS distributions. Meson's
built-in support for subprojects expects to find them in ./subprojects
at top level.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This checks that the value of the REF field is not an empty string
before calling `flatpak_decomposed_new_from_ref`. Attempting to
decompose an empty string leads to a validation error and prevents
any history from being printed.
Fixes https://github.com/flatpak/flatpak/issues/4121
The system helper was already correctly using the `NO_INTERACTION` flag
in the D-Bus call flags to determine whether polkit calls from
`flatpak_authorize_method_handler()` should allow interactivity.
However, the system helper was not setting the no-interaction property
on the `FlatpakDir` used in the subsequent operation. When parental
controls are enabled, this sometimes results in polkit allowing
interaction when prompting for the `override-parental-controls` action,
even if the D-Bus call which activated the system helper specified the
`NO_INTERACTION` flag.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
For reasons unknown, libarchive appears to generate broken gnutar format
tar archives when the archive contains files that are larger than 2 GB.
This commit switches to the pax format to work this around.
This should be a better default as it also removes 256 char filename
length limitation and matches what other libraries are doing, e.g.
Python 3.8 switched to the pax format by default as well.
See https://pagure.io/fedora-infrastructure/issue/9840
Currently the create-usb command copies extra-data flatpaks such as the
org.freedesktop.Platform.openh264 runtime extension along with normal
non-extra-data content. This is an issue because on the computer
installing from the USB it will attempt to get the extra-data content
from the URI specified in the commit metadata, which will fail if the
URI is a resource on the Internet and the computer is offline.
Instead, have create-usb omit such refs. If it was specified explicitly
this is treated as a hard error and if it's a dependency it's treated as
a warning, so that e.g. org.freedesktop.Platform can still be copied to
a USB and installed/updated offline. On the receiving end the absence of
org.freedesktop.Platform.openh264 will correctly not be treated as fatal
to the installation of org.freedesktop.Platform.
This issue was affecting offline updates of Endless OS, since such OS
updates include flatpaks along with the OS content.
For the (legally questionable) topic of properly supporting extra-data
distribution offline, see https://github.com/flatpak/flatpak/issues/969
We sometimes set a custom per-thread mainloop because and then spin it
manually to fake a sync call on a thread using async calls. Primarily
this happens with the soup streaming calls. In this case, eventually
we finish the main loop iteration (because, say, the download is done)
so we stop iterating the mainloop and return from the fake sync code.
However, that might not necessarily be the only thing queued on the
main context. I ran into a situation where it seems like libsoup did
some call to a thread-pool during the async call, and the next time i
used soup aync everything froze. It looks like there is some threaded
soup service that returned a response on the old context, and since
that never got handled (since that context is now dead) it now doesn't
work.
To solve this situation we're now iterating the main context until
there are no pending sources before killing the main context.
We're calling async soup APIs with SOUP_SESSION_USE_THREAD_CONTEXT
set, which means that libsoup async APIs will run async callbacks on
the loop of the thread-default main context. We then manually spin
this main context, because we're supposed to look like a sync call and
the async stuff is just internally.
This is not really right, because normally there isn't any custom
mainloop context registred, which means we're spinning the main thread
context on some other thread, as well as queuing soup sorces on
it. This can't be any good!
Rather than doing this we actually create and push our own main
context that we then spin isolated from the default mainloop.
For updates in remotes with a local (file:) uri we just do a deploy
with a LOCAL_PULL flag set and an empty arg_repo_path. However, our
arg_repo_path checking at some point seemed to stop properly handling
the case where it is empty. I got it to report "No such file" wich
broke the tests.
Previously, the polkit query was always interactive, even if the
`FlatpakDir` was operating in non-interactive mode (for example, for a
background update in gnome-software). Make the interactivity match the
interactivity of the `FlatpakDir`.
Do the same for the `mct_manager_get_app_filter()` call, although this
is less important since under normal conditions it will never prompt the
user.
This should hopefully stop polkit prompts appearing periodically when
background updates are being done while logged in as a non-privileged
user with parental controls set to prevent application installation.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
On a decently fast system, some files may be fetched, modified and then
fetched again within the same second. In that case, the web server
replies with a code 304 ("Not modified") to the 2nd query, causing some
tests to fail.
This commit forces the web server to ignore `If-Modified-Since` HTTP
headers, effectively disabling caching in order to mitigate the problem.
If we can get people to report security issues privately, then we can do
coordinated disclosure instead of having to rush to fix issues that are
already known to the public.
This is either a malicious/compromised app trying to do an attack, or
a mistake that will break handling of %f, %u and so on. Either way,
if we refuse to export the .desktop file, resulting in installation
failing, then it makes the rejection more obvious than quietly
removing the magic tokens.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we add new features analogous to file forwarding later, we might
find that we need a different magic token. Let's reserve the whole
@@* namespace so we can call it @@something-else.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Distributions run these tests on other architectures, but hard-coding
x86_64 to look for in output dooms that to failure.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The "new way" is supported since at least 2010 (!).
app/parse-datetime.y:302.1-12: warning: deprecated directive: ‘%pure-parser’, use ‘%define api.pure’ [-Wdeprecated]
302 | %pure-parser
| ^~~~~~~~~~~~
| %define api.pure
As it uses directives that POSIX yacc doesn't support:
app/parse-datetime.y:302.1-12: warning: POSIX Yacc does not support %pure-parser [-Wyacc]
302 | %pure-parser
| ^~~~~~~~~~~~
app/parse-datetime.y:307.1-7: warning: POSIX Yacc does not support %expect [-Wyacc]
307 | %expect 31
| ^~~~~~~
The serial number is supposed to appear only once per file, at the top
of it. Add a serial that matches the highest serial and remove the
in-text serials.
acinclude.m4:113: warning: the serial number must appear before any macro definition
acinclude.m4:321: warning: the serial number must appear before any macro definition
Use present tense consistently rather than gerunds for some headings in
"flatpak --help". Also tweak flatpak(1) to use similar wording but with
gerunds.
When the portal's Spawn method is used with the environment cleared,
it's very likely that the "flatpak run" that ends up being run will be
in an environment without UTF-8 support.
If one of the files or directories we try to expose to the sub-sandbox
contains UTF-8/non-ASCII characters, then "flatpak run" would fail with:
error: Invalid byte sequence in conversion input
This is caused by GOption trying to parse the --filesystem option for
flatpak, as, when using the G_OPTION_ARG_CALLBACK argument type, GOption
will split the option name from its value, and try to convert the value
to UTF-8. Which will fail because there's no UTF-8.
It won't however do that if we tell the option parser that the value is
a filename using G_OPTION_FLAG_FILENAME, so set it.
OpenSUSE inherits the hostname value from DHCP without updating its X11
authentication cookie, and it keeps the initial value in
`XAUTHLOCALHOSTNAME`.
To avoid breaking the X11 applications, OpenSUSE patches libxcb so that
it also considers the value in `XAUTHLOCALHOSTNAME` as another possible
hostname.
https://bugzilla.opensuse.org/show_bug.cgi?id=262309
To cope with that behavior we need to check `XAUTHLOCALHOSTNAME` too
and, if we have a cookie with that address, propagate it inside the
container adjusting its address to the canonical hostname
`unames.nodename`.
Fixes: #4043
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
Currently if a user of libflatpak wants to list the related refs (such
as extensions and plugins) of something, they have three options:
1. They can parse the metadata manually with e.g.
flatpak_remote_ref_get_metadata() and then key-file operations, but
this means re-implementing parts of libflatpak and using key file
strings that are not actually public (FLATPAK_METADATA_KEY_...).
2. They can use flatpak_installation_list_installed_related_refs_sync()
but this only works for installed related refs not remote ones.
3. They can use flatpak_installation_list_remote_related_refs_sync() but
this lists all remotely available related refs, including ones that
may not be compatible with the installed version of the main ref
(because they don't match any of the values in the "versions"
metadata key).
So since none of these provide a way to get the remote related refs
corresponding to an installed application, add new API for that. For the
motivation of this see
https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1132
FLATPAK_ERROR_ALREADY_INSTALLED can be returned from, for example,
flatpak_installation_add_remote(), so document that it applies to
remotes not just apps and runtimes.
