This adds a new error to FlatpakError and uses it everywhere a ref is not
found, either locally or in a remote. This should hopefully be more useful than
the status quo of either returning FLATPAK_ERROR_INVALID_DATA or
G_IO_ERROR_NOT_FOUND or something else. Technically this is an API break but it
seems worth the risk. I checked gnome-software which does not seem affected by
this, and I checked eos-updater which does check for G_IO_ERROR_NOT_FOUND in
one place that will be affected by this but we can patch that.
Closes: #2895
Approved by: matthiasclasen
As described in the last commit message, it makes sense to move toward
using flatpak_repo_resolve_rev() rather than ostree_repo_resolve_rev()
for a few reasons:
1) It means we can use OSTREE_REPO_PULL_FLAGS_MIRROR which causes refs
to be pulled into repo/refs/mirrors/ rather than repo/refs/remotes/
which fixes a few edge cases of using collection IDs[1]
2) It falls back to using ostree_repo_resolve_rev() if
ostree_repo_resolve_collection_ref() fails so we can maintain backwards
compatibility for repo/refs/remotes/
3) It distinguishes between remote and local refs, and in the local case
uses OSTREE_REPO_RESOLVE_REV_EXT_LOCAL_ONLY and
ostree_repo_resolve_rev_ext() to make sure we don't for example
accidentally use a remote's repo metadata rather than the local repo's
metadata for the "flatpak repo" command.
So this commit changes every instance of ostree_repo_resolve_rev() in
the codebase to flatpak_repo_resolve_rev().
[1] https://github.com/flatpak/flatpak/issues/1832Closes: #2705
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
In general xa.filter being "" means don't filter, so that it can be
used to override-unset a previous filter. However, We canonicalize
to unset/NULL when comparing, returing, or setting the ostree config.
Closes: #2884
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
readlink() and readlinkat() have weird semantics (they return the
number of bytes they would have written if there was enough space,
even if that's larger than the buffer), but glnx_readlinkat_malloc()
takes care to do the right thing in all situations.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2873
Approved by: matthiasclasen
For compatibility with libappstream we create a $origin ("flatpak")
subdirectory with symlinks to the size directories thus matching the
standard merged appstream layout if we assume the appstream has
origin=flatpak, which flatpak-builder creates.
See https://github.com/ximion/appstream/pull/224 for details.
Fixes https://github.com/flatpak/flatpak/pull/2779Closes: #2789
Approved by: alexlarsson
Rather than creating a real temp directory and
then commiting that we generate an in-memory mtree
which mostly refers to pre-existing icon file
objects, and then the newly created appdata xml.
Closes: #2753
Approved by: alexlarsson
Uncrustify has an option "nl_func_var_def_blk" which is supposed to
ensure there's a newline character between the block of variable
definitions and the rest of the function body, but it gets confused and
thinks that the first instance of "g_autoptr" or "g_auto" being used on
a variable is the start of the function body. So this commit removes
those extra newline characters and removes that option in uncrustify.cfg
so they don't get re-added the next time uncrustify is run.
Here's the command I used:
perl -0777 -i -pe 's/\n(\n\s*g_auto\()/\1/g' `git ls-tree --name-only
-r HEAD | grep \\\.[ch]$ | grep -v common/valgrind-private.h |
grep -v app/flatpak-polkit-agent-text-listener\\\.[ch]`
I ran it again with "g_autoptr" in place of "g_auto", and made a few
manual edits to add back the newline when the g_auto* was in the middle
of a function body rather than at the top.
Closes: #2715
Approved by: matthiasclasen
Edit uncrustify.cfg to add options to remove extra newlines near opening
and closing braces, and run uncrustify again.
Closes: #2715
Approved by: matthiasclasen
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
For whatever reason, in the buildbot environment the TIOCGWINSZ
ioctl returns a 0x0 size, which causes a divide by zero. We
handle this by returning a default 80x24 size.
Closes: #2685
Approved by: alexlarsson
This lets us export D-Bus service files for
names like org.foo.Bar.Application.Tracker.service
when the app-id is org.foo.Bar.
Closes: #2615Closes: #2616
Approved by: alexlarsson
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
'flatpak install sdk' offers me 34 choices, so double digits
seem very realistic here. Make the numbers line up in this
case.
Closes: #2476
Approved by: matthiasclasen
This adds a version to the deply data format, assuming that if
there is no version then it is 0. Also extends all loaders so that
it can specify a required version, with the goal that most users
are fine with old versions, but if you need more recent we have
a (costly) conversion process to upgrade (will be added later).
The library and the flatpak list/info commands require the most
current version for full info, all other users can use any version.
Also, as part of this we now pass the ref to flatpak_load_deploy_data()
as this will be needed later for the backwards compat support.
Closes: #2409
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
It happens sometimes that the first processed total is 1, when this gets
downloaded we have 100% already and then the total changes making this
percentage faulty.
This makes the progress regress sometimes, but I'd say it's better than
a permanent, ficticious number.
Fixes#2428
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
Firstly this changes the "download-if" and "enable-if" properties
to accept a `;` separated list of multiple conditions.
Secondly it adds `on-xdg-desktop-*` which will check against
the XDG_CURRENT_DESKTOP env var (case-insensitively).
This is done entirely for the Qt GNOME Platform so it can do this:
```
"org.kde.PlatformTheme.QGnomePlugin" : {
"download-if": "on-xdg-desktop-GNOME;on-xdg-desktop-GNOME-classic"
}
```
Closes: #1436
Approved by: matthiasclasen
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
