flatpak build-update-repo now lets you modify the
autenticator-name/install/options keys, and these are migrated to
the summary/metadata during update.
With the latest ostree that enables the chaining of progress the
testsuite broke because we were not getting changed events. Looking
into this the reason seems to be that when we run the
ostree_async_progress_finish() on the chained progress it is marked
as dead, which causes ostree_async_progress_copy_state() to not copy
any data when called from handle_chained_progress().
The fix is to copy the content manually before calling the finish().
Also, the entire callback chaining system seems wildly
overcomplicated, so I simplified it by relying on the existing change
notification of OstreeAsyncProgress.
This is a g_autoptr version of OstreeAsyncProgress that also
calls ostree_async_progress_finish() before being freed.
This should be used in all "leaf" functions that creates an asyncprogress
to avoid leaking any idle change idle sources. Using a auto* means
some code can be cleaned up to avoid goto out style handling for this.
Also, this adds a missing finish() in
_flatpak_dir_fetch_remote_state_metadata_branch().
If we're using a chained progress, it will be unchained
in the destroy notifier. However, it was newly constructed so we
need to also unref it or we'll leak it.
This also makes some minor cleanups:
1) Centralize version checks to one place and replace users
with #ifdef FLATPAK_DO_CHAIN_PROGRESS which makes it
easier to read and to test the fallback.
2) Make flatpak_progress_chain return a FlatpakAsyncProgressChained
to make it clear the two needs to be paired.
The autoptr cleanup function for FlatpakRepoTransaction depends on the
OstreeRepo object that it was created with still being alive. If the
repo object is also an autoptr then it can depend on the order the
variables were declared in whether this works or crashes.
That is obviously an evil trap, so have FlatpakRepoTransaction take a
ref on the repo object and release it in the autoptr cleanup function,
in case the repo's autoptr cleanup function runs before that of
FlatpakRepoTransaction.
It's a common idiom in this codebase to push a temporary GMainContext as
the thread default context in order to run an async operation as if it
were sync. If we are not expecting progress callbacks this isn't a
problem, but it becomes a problem if we pass in an OstreeAsyncProgress
object that was created under a different GMainContext. The reason for
this is that OstreeAsyncProgress creates an idle source and attaches it
to the thread default context, so if we are iterating a temporary
context then the OstreeAsyncProgress's context never gets iterated, and
so no progress signals are fired.
To fix this, we introduce flatpak_progress_chain() and a RAII helper
FlatpakAsyncProgressChained which creates a new OstreeAsyncProgress
under the temporary GMainContext, but forwards all its state and updates
to the previous OstreeAsyncProgress's callbacks.
This is documented in a comment in the code as well.
All known instances of this problem in the existing code are fixed in
this commit.
This uses new API in libostree which is proposed in
ostreedev/ostree#1968. In anticipation of it being included in libostree
version 2019.6, the bug fix is predicated on that version being present.
If compiling against an older version, the old buggy behaviour will be
the fallback.
This problem was solved conceptually by Philip Withnall, I only wrote
the code.
This means you can use "org.foo.bar//stable" instead of "org.foo.bar/*/stable"
which is similar to what other APIs do.
We want to use this for masking extensions too, thus the export.
flatpak_dir_collect_deployed_refs() has the order of its "branch" and "arch"
arguments wrong, as does its only caller flatpak_list_deployed_refs().
When flatpak_list_deployed_refs() is called by add_extension() the arch
is put in the branch argument and vice versa. But then in the
implementation the arch is used as if it's the branch and vice versa, so
there's no functional bug here. Fix the order for readability.
Similarly, flatpak_list_unmaintained_refs() has the order wrong, but the
confusion is only within that function, since the order is correct in
its caller add_extension() and in the function it uses,
flatpak_dir_collect_unmaintained_refs(). So there's no functional bug
there either, but fix the order.
Closes: #3067
Approved by: alexlarsson
When we export a manifest to the index, always pass the ref we're
targeting instead of relying on the org.opencontainers.image.ref.name
annotation, because that may not be set if we're using labels instead.
This is no big deal, because we know what ref we're handling anyway.
Closes: #2978
Approved by: alexlarsson
We now pull the image config as well as the manifest and fall
back on the labels field if the keys we're looking for are not
in the annotations field.
This lets us support docker manifests too, which don't have
annotations (but do have labels).
Closes: #2978
Approved by: alexlarsson
The org.freedesktop.Flatpak user D-Bus service isn't just used by
flatpak(1) or applications running as Flatpaks. It's also used by
toolbox(1) for similar reasons:
* To keep various configuration files inside the container
synchronized with the host
* To let the container request certain commands to be run on the host
The org.freedesktop.Flatpak D-Bus service itself doesn't need much in
the way of dependencies, but inherits a lot of unused shared library
linkages through the libflatpak-common.la convenience library. Removing
these unused shared libraries reduces the footprint of toolbox(1) for
those who care about such things. eg., Fedora CoreOS.
This commit brings down the number of shared libraries to 19 from 62.
Closes: #3052
Approved by: alexlarsson
... by moving the definition of FlatpakHostCommandFlags from the
'common' sub-directory to 'session-helper'. It hasn't been used by
anything else ever since flatpak-builder was moved to a separate
repository in commit 52bd146561.
Closes: #3052
Approved by: alexlarsson
In flatpak_dir_do_resolve_p2p_refs() after pulling a ref we use
ostree_repo_resolve_rev() and pass a refspec with the remote from which
the ref originated. This has a couple side effects, one good and one
bad:
1) The good side effect is that the attack I speculated about in this
comment[1] is not exploitable. Because if the ref in question is pulled
from any remote other than its origin (or a LAN/USB source using another
remote's keyring) it will not be found by ostree_repo_resolve_rev() and
the malicious commit will not be used.
2) The bad side effect is that there are some legitimate reasons a ref
could be pulled from another remote (say, a configured mirror), and in
those cases the pulled ref will not be found. So if I have remote A and
remote B both configured with the same collection ID, a ref installed
from one could be pulled from the other. See this issue[2] for a
concrete example.
The solution is to use OSTREE_REPO_PULL_FLAGS_MIRROR for the pull and
use ostree_repo_resolve_collection_ref() to resolve the ref. This is
done in the caller as well for consistency
(flatpak_dir_resolve_p2p_refs()). This fixes the bad side effect
described above and brings us a step closer to fixing issue #1832. This
also means the attack from #1447 is exploitable, but that is addressed
in a subsequent commit.
This change is conditional on a version check for OSTree 2019.2 because
we need this bug fix[3].
Also, add a helper function flatpak_repo_resolve_rev() which falls back
to using ostree_repo_resolve_rev() when
ostree_repo_resolve_collection_ref() fails, so we start to move toward
using /refs/mirrors/ but maintain backwards compatibility for
/refs/remotes/. A subsequent commit will make wider use of
flatpak_repo_resolve_rev() across the codebase; for now just use it for
the case described above.
[1] https://github.com/flatpak/flatpak/issues/1447#issuecomment-445347590
[2] https://github.com/flatpak/flatpak/issues/1832
[3] https://github.com/ostreedev/ostree/pull/1821Closes: #2705
Approved by: alexlarsson
This is in preparation for writing some unit tests
for these functions. Apparently they are not too
trivial to get them wrong.
Closes: #2880
Approved by: alexlarsson
Filters are specified as a list of
op glob
where op can be allow or deny, and the blogs are partial refs
where * means anything in this part of the ref, and non-specified
trailing parts of the ref matches anything.
By default everything is allowed, but if you specify some
deny rules all that they match is denied, except if there is
an specific allow rule.
Internally this takes all the allow and deny globs and convert
them into two combined regular expressions.
Some examples:
* - match anything
app/* - match all apps
runtime/* - match all runtimes
app/*/x86_64 - match all x86-64 apps
app/org.gnome.*/*/stable - match all stable gnome apps
org.gnome.frogr* - match frogr and extensions
This means you can do a both whitelisting:
deny *
allow org.the.good.app*
Or blacklisting:
deny org.the.bad.app*
Closes: #2869
Approved by: alexlarsson
Whenever we use $XDG_RUNTIME_DIR and expose it somehow in the sandbox
we fully resolve the path, because if (as happens on gentoo for instance)
it contains /var/run -> ../run, then flatpak thinks we need to
add the /var/run symlink in the runtime even though we already
exposed that.
Closes: #2710
Approved by: matthiasclasen
This is a variant that allows to enter multiple numbers,
either individually, or as range. Parts can be separated
by space or comma. Examples:
1-3,5
1 2 4
6
Closes: #2559
Approved by: alexlarsson
This prints the common pattern of
Choices:
1) bla
2) bla
with consistent formatting, so we don't have
to worry about matching newlines and spaces
all over the codebase.
Closes: #2371
Approved by: alexlarsson
Add a function to query the window size and cursor position,
and definitions for some more ANSI escape sequences that we
will use in the following commits.
Closes: #2371
Approved by: alexlarsson
This lets us respect the fancy output setting, and
it lets us do some other things that make it better
integrated.
Closes: #2379
Approved by: alexlarsson
Add flag that instructs the session-helper to kill
the spawned command when the caller drops off the bus.
Closes: #2326Closes: #2365
Approved by: alexlarsson
When installing a flatpak with extra-data we execute the apply_extra
script from the flatpak to extract the extra data files we
created. This script runs with very little filesystem acces, but it
does have write permissions to the location that will eventually be
/app/extra in the finished flatpak. This is especially problematic for
the systemwide install case, because the script is then run as root,
so it could potentially create a setuid file there.
Such a file would not be usable inside the sandbox (because setuid is
disabled in the sandbox), but it could potentially be a problem if the
user could be tricked into running the file directly on the host. This
is the same behaviour as e.g. rpm or deb which both can install setuid
files, but we want to guarantee that flatpak is better than that.
The fix is to run the script with all capabilities dropped (bwrap
--cap-drop ALL) which removes a bunch of possible attack vectors (for
instance setting file capabilities). However, even without
capabilities, it is possible for a user to make any file setuid to the
same user, so we also need to canonicalize the permissions of all
files generated by running the script.
Additionally, while running the script we set the toplevel directory
only be accessible to the user, meaning we will not temporarily leak
any potential setuid files to other users.
Note, this commit actually goes furthen than that and completely
canonicalizes all the file permissions to be the same as those
otherwise used by flatpak. For example we fix up cases where the
script creates files writable or unreadable by non-root users.
Closes: #2323
Approved by: alexlarsson
This commit implements a feature in the multiple choice prompt that
mirrors the behavior in the yes/no prompt where it can default to "yes"
when the user only presses Enter. In the case of the multiple choice
prompt, it only defaults to the first choice on Enter if there's only
one option (e.g. you're asked if you want to install from the "flathub"
remote as opposed to being asked to choose between the "flathub" and
"eos-apps" remotes).
This feature can be turned off on a per-prompt basis if we want explicit
user input for something but I didn't find that necessary for any of the
existing prompts.
Also note that as with the yes/no prompt defaulting to yes on Enter,
this only applies for interactive terminals. If Flatpak is being run by
a script no choice will be made automatically.
This should save users unnecessary keystrokes, such as when they use
"flatpak install devhelp" and are asked to confirm that the Flathub
remote is the one to use (now they can just press Enter).
Closes: #2288
Approved by: matthiasclasen
Currently when the Flatpak command line prompts the user with a yes or
no question, the user must type "y" or "n" to respond. This commit
changes it so that the prompt can assume "yes" if the user just presses
Enter. In that case the prompt ends in "[Y/n]" rather than "[y/n]". If
there are some operations that are considered dangerous, we can still
require explicit user input on those, but as far as I can tell those
criteria don't apply to any existing prompts.
This behavior of allowing the user to just press Enter is consistent
with how apt works for example.
Note that this is distinct from the "--assume-yes" option we have, since
that won't prompt the user at all when a decision needs to be made.
Closes: #2113
Approved by: matthiasclasen
This moves the implementation of the Levenshtein "edit distance"
algorithm from app/ to common/ so it can be used in an upcoming commit.
Closes: #2113
Approved by: matthiasclasen
Neither flatpak_variant_builder_init_from_variant nor
flatpak_gvariant_new_empty_string_dict are used anywhere.
Closes: #2252
Approved by: matthiasclasen
