Now that we are logging `flatpak -v` messages with log level INFO,
and printing INFO messages in the same way as DEBUG, we can reserve
log level DEBUG for `flatpak -v -v` messages. This means we no longer
need a weird secondary debug domain.
There is a very small behaviour change here: G_MESSAGES_DEBUG=flatpak
is now similar to `flatpak -v -v` (previously `flatpak -v`), and
G_MESSAGES_DEBUG=flatpak2 no longer has any effect. This seems more in
line with what would be expected from a GLib-based application.
In flatpak(1) and the system helper, this does not change behaviour
other than that: the same messages are logged by `-v` and by `-v -v`
as before.
In daemons that do not implement `-v -v` (the OCI authenticator, portal
and session helper), it continues to be necessary to use
G_MESSAGES_DEBUG to see flatpak_debug2() messages.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This brings us one step closer to being able to stop using the flatpak2
log domain for messages that are exclusive to `flatpak -v -v`.
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_memdup() is subject to an integer overflow on 64-bit machines if the
object being copied is larger than UINT_MAX bytes. I suspect none of
these objects can actually be that large in practice, but it's easier
to replace all the calls than it is to assess whether we need to
replace them.
A backport in libglnx is used on systems where GLib is older than 2.68.x.
Signed-off-by: Simon McVittie <smcv@collabora.com>
To make indentation work with less effort. The modeline was copied from
libostree with minor modification and the .editorconfig from GLib.
The advantage of having both a modeline and an editorconfig is we can
work out of the box on more editor setups, and the modeline allows us to
specify the style with a lot more fine grained control.
When Flatpak's P2P updates support was replaced with the "sideloading"
implementation in 1.7.1, a new server side repo config key
"deploy-sideload-collection-id" was added which gets set when you pass
"--deploy-sideload-collection-id" to "flatpak build-update-repo", and
has the effect of setting "xa.deploy-collection-id" in the repo metadata
that is pulled by clients, which itself causes a collection id to be set
on the remote for clients using Flatpak >= 1.7.1.
This commit adds an analogous key in flatpakref and flatpakrepo files,
so the collection id can be set when the remote is configured, rather
than later on when the repo metadata is pulled and acted upon. As before
with DeployCollectionID, it has no difference in function compared to
DeployCollectionID or CollectionID and the only difference is which
Flatpak versions are affected.
It would've been better if this were added in 1.7.1 when the sideload
support was added, but alas here we are.
(Also update the docs and unit tests)
Currently if a runtime extension, e.g.
org.freedesktop.Platform.html5-codecs//18.08 is used by a runtime
org.kde.Platform//5.12 which itself is used by one or more apps, when we
print a message to the user about html5-codecs being EOL, we don't find
any apps using it and don't print any. Fix this by including apps that
indirectly use a runtime extension in the "Applications using this
runtime:" list.
In a later commit we can re-use the helper function added here to add a
confirmation dialog if the user tries to remove a runtime extension
that's being used; currently we just let them remove it.
This is limited to only looking in the current flatpak installation, so
a per-user app using a system-wide runtime extension would not be found.
This is implemented using in-memory caches because otherwise it is
horribly slow; see
https://github.com/flatpak/flatpak/pull/4835#discussion_r876425289
Helps: #3531
We support the "summary-arches" variable to limit which arches goes
into the compat summary file. However, its currently always adding in
the compat arches of whatever arches you list. This means we can't
e.g. keep compat summary support for aarch64, but not for armv7, which
is a problem as we're nearing the 10MB summary size limit of ostree
for old clients.
So, just keep the exact arches listed. If you want to keep compat
arches, you need to explicitly list them.
As discussed in #4848, this disables fuzzy matching entirely if stdin or
stdout is not a tty, meaning that something like "flatpak install
firefox" would be treated as incorrect syntax, since this syntax is
intended for interactive CLI use. Even before this commit, "flatpak
install firefox" would error out if run without a tty, since we don't
automatically choose a matching app ID even if there is only one match.
However "flatpak install -y firefox" could work before, but won't any
more. People should be specifying the full app ID in any context other
than a tty.
This commit also introduces a new env var so the unit tests can continue
to check the fuzzy matching behavior, despite them being run without a
tty.
Recent Meson versions have warnings if you add the subprojects
directory as an include path, because the way Meson wants to consume
subprojects is by the subproject's build system producing a Meson
dependency object that encapsulates its include directory. Flatpak
doesn't have a Meson build system yet, but I'm working on that.
libglnx seems to be set up to have the libglnx directory be its include
path instead: for example, ostree (by the author of libglnx) already
uses "libglnx.h" or <libglnx.h> everywhere. Do the same here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Just as we already call flatpak_disable_fancy_output() in
flatpak_option_context_parse() in case verbose output is enabled via CLI
options, disable fancy output in case verbose output was enabled via the
G_MESSAGES_DEBUG env var. Without this change, the result of doing e.g.
$ G_MESSAGES_DEBUG=OSTree flatpak install ...
is pretty useless and ugly, when the output isn't being redirected to a
file, since the debug messages are overwritten when we redraw to show
progress updates.
This makes the output of "flatpak list" a bit ugly when G_MESSAGES_DEBUG
is set, but it seems like a small price to pay.
In particular, if a null terminator is placed inside the metadata file,
Flatpak will only compare the text *before* it to the value of
xa.metadata, but the full file will be parsed when permissions are set
at runtime. This means that any app can include a null terminator in its
permissions metadata, and Flatpak will only show the user the
permissions *preceding* the terminator during install, but the
permissions *after* the terminator are applied at runtime.
Fixes GHSA-qpjc-vq3c-572j / CVE-2021-43860
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
The history command seems to have been broken since it was changed to
use FlatpakDecomposed, since that type only works for app or runtime
refs, resulting in errors such as:
$ flatpak history
error: appstream2/x86_64 is not application or runtime
Fix this by making the logic a bit smarter, and don't let any one
invalid ref entry prevent the whole command from working.
Fixes#4332
Have heard of people running Flatpak commands with both sudo and --user,
and not expecting it work on the root user's installation. Let's just
not allow it since it's not something people ever do intentionally.
On two different code paths we were using the "Title" field in
flatpakref files as the title of a remote, which is incorrect. In most
cases, the remote added via the RuntimeRepo key will be the same as the
remote the app is from, so when the remote is added for the runtime, its
title will be correctly set using the Title value from the flatpakrepo
file and the app will therefore have an origin remote with a title set.
This is not currently true for flatpakref files that use
SuggestRemoteName=, see https://github.com/flatpak/flatpak/pull/4513
For flatpakref files that use a different remote than the RuntimeRepo,
we don't currently have a way for the title to be set automatically;
perhaps we should (https://github.com/flatpak/flatpak/issues/4512).
Fixes https://github.com/flatpak/flatpak/issues/4499
This is similar to what is done for desktop files and allows
applications to use a flatpak's metainfo to retrieve e.g. required
input controllers or the supported screen sizes. Similar to what can be
done for non-flatpak'ed apps by looking at
/usr/share/{metainfo,appdata}.
Since flatpak moves the metadata from metainfo/ to appdata/ during build
we only need to export files from that single directory.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Many of the fields allowed in flatpakrepo files are not allowed in
flatpakref files, e.g. Comment, Description, Homepage, etc. So there is
no straightforward way to ensure those are set correctly when the user
installs something with a flatpakref file. However in most cases the
repo specified by the RuntimeRepo key is also the repo providing the
main ref, so in those cases it makes sense to utilize all the metadata
provided in the flatpakrepo file when creating a remote to provide
updates for the app being installed. We were already doing this when the
SuggestRemoteName key was unset; this commit makes it so that we utilize
that metadata also when SuggestRemoteName is present.
Even though we are going to check all the `LC_*` environment variables,
if one of them is not set, we still need to consider LANGUAGE, LC_ALL
and LANG; there is no guarantee that *every* `LC_*` environment variable
is set (and in particular, during our build-time tests, they will usually
not be).
Resolves: https://github.com/flatpak/flatpak/issues/4471
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_get_language_names() only returns the language names for the
LC_MESSAGES category, so mixed locale scenarios would result in missing
languages. Now, the languages are listed for each individual category.
Note that this issue was only present with the user installation. For
the system installation, the locales were queried from localed, and all
categories were checked.
In order to work on GLib versions < 2.58, the code to get language
names for a category has been backported.
Fixes#3712.
These functions were already annotated with G_GNUC_PRINTF, so gcc
can assume that the format string and arguments match up.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Without this change, validate_component() might free the "component"
variable, but then go on to keep using it. This change also makes the
code work as intended, to only have a flatpak-specific "bundle" in the
appstream xml (where here bundle does not mean "flatpak single-file
bundle").
If an argument takes a value, and the value is empty, then it's
misleading to quote `{"--foo", "--empty", "", "--bar"}` as
`--foo --empty --bar`. It's better to get `--foo --empty '' --bar`.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This has no practical effect (assuming environment variables are unique),
but it makes it easier to find an environment variable of interest
in a very long bwrap command-line.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes them easier to deal with when debugging. Otherwise, it's easy
for the bundled arguments to wrap across 50 or more lines, and with
linebreaks in arbitrary positions that becomes very hard to read.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In addition to the old summary.idx.sig we now create an identical file
in `summaries/$DIGEST.idx.sig`, where the digest is of the summary
index itself. This means it will have a unique name and there will
never be issues where downloading the index and signature will race
during an update.
We keep the new and the previous digested sigs every update to avoid
removing the previous one while its in use.
As suggested by simon in https://github.com/flatpak/flatpak/issues/3983
and https://github.com/ostreedev/ostree/issues/2250
Currently if a deploy file was created (because a flatpak is installed)
using an old Flatpak version (such as 0.10.1 that's in Endless 3.3.16),
it will not include every metadata key, such as "eol" and "eolr". Those
keys were added before deploy version 1. Then when the deploy file is
upgraded to version 3, the metadata is only copied so eol/eolr are still
missing even though they exist in the commit metadata.
So this commit adds deploy version 4 which ensures all metadata keys in
the deploy file are present (when they are present in the source data).
All existing deploy files will be upgraded with this code.
This change is important because we use the end-of-life information to
decide whether an unused runtime should be uninstalled, so without this
change we are not freeing up disk space that we should be.
When installing to an installation we need to find the runtime to use
for the apply-extra-data script from the installation we're targeting,
because that is the one that FlatpakTransaction guaranteed has the
required dependencies (although its possible they came from the
default dependency source too, i.e. the system repos).
In particular, we run into this issue if nothing is installed
anywhere, and then we install an extra-data app into a custom
directory. The transaction will download the runtime, and it
will not be anywhere else. Without this change flatpak only
looked for the dependency in the systam an regular user dirs
where it isn't.
The old summary had a ostree.commit.timestamp in the per-ref metadata
dict. However, since this was not used anymore by flatpak I removed it.
However, it turns out that flathub has infra that depends on this,
so I'm adding it back.
We reuse the data in the old summary for unchanged refs when
rebuilding the summary, to avoid having to read all the commits. In
the new world the new format summaries are used for this, which means
we have to keep the timestamp in that too. However, to not be
unnecessary large its now using a shorter key name, as this is
duplicated for each ref in the summary.
There was a bug in the extension point matcher which made it
install `org.gnome.Totem.Videosite.YouTubeDl.Sources` (in addition to
`org.gnome.Totem.Videosite.YouTubeDl`) for the `org.gnome.Totem.Videosite`
extension.
We just need to make sure we only match the extension prefix if there
is a single element in the extension name following the extension
name (i.e. '.YouTubeDl', not '.YouTubeDl.Sources').
This fixes https://github.com/flatpak/flatpak/issues/3973
In the main summaries we drop all the subset appstream branches.
In the subset summaries we use the relevant appstream branch and drop
the normal ones.
We also leave out the old compat branch completely from the subset
summaries because it will just be used for newer flatpaks that support
the new format.
