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
There's no point building up the options GVariant for a find or a pull
that doesn't happen, so move that work to the innermost scope.
As an aside, it's much more pleasant to look at the diff for this commit
using git's --patience option than the default diff algorithm.
Closes: #2705
Approved by: alexlarsson
A *.flatpakrepo file in this directory will be automatically
added as a system remote with the basename (sans extension) as the
name unless that name already exist. Also, once this is done we
record the name in the repo config so that it is not applied again if
the remote is removed.
Closes: #2884
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 kind of remotes don't work very well, because they are not modifiable
or removable and can cause conflicts with pre-existing remotes.
We instead want to switch to a way to define default remotes that
is applied to the regular ostree repo config, allowing later changes.
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
This is kind of special as it handles non-existing filter keys
as "override to no filters" instead of "leave existing filters" whic
we do for other things. However, that matches how we want to use
.flatpakrepo files to override site-local filters.
Closes: #2869
Approved by: alexlarsson
If there is a filter for the remote, include the checksum of it
in the directory name for the deploy dir. This way we re-deploy the
appstream if the filter changes.
Closes: #2869
Approved by: alexlarsson
This means only refs that are allowed will be visible in the deployed
appstream.
This sometimes means we have to uncompress the xml.gz before rewriting
and then re-compressing that.
As a result of this we now always end up with both the compressed and
the uncompressed xml file, whereas we before didn't get an uncompressed
one if the remote was using the old appstream format.
Closes: #2869
Approved by: alexlarsson
Full names are:
* flatpak_remote_state_lookup_ref()
* flatpak_dir_list_all_remote_refs()
This should be enough to not get any stray refs, because due to the
complexities of p2p all accesses go via FlatpakRemoteState.
The one leftover to non-filtered stuff is the appstream file, a later
commit will handle that.
Closes: #2869
Approved by: alexlarsson
If this is set to a pathname in the configuration of a remote we load
that file and keep track of it as a filter. No filter is actually applied
yet though.
There is two levels of caching, consecutive lookups of the filter
with less than 500msec between use the previous value. Once its more
that that we stat() the file and compare the mtime, reloading the file
if the mtime changes. We also directly reload the file if the pathname
changes.
Closes: #2869
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
The function was already leaking the result of
extract_unix_path_from_dbus_address() in the case where that call
succeeded. Since commit 0e545799 it would also leak the result of
g_build_filename in the case where it checked $XDG_RUNTIME_DIR/bus.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2877
Approved by: matthiasclasen
This matches what's now implemented in libdbus, GDBus and sd-bus.
If $DBUS_SESSION_BUS_ADDRESS is unset, check whether $XDG_RUNTIME_DIR/bus
is a socket owned by Flatpak's uid; if it is, use it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2874
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
There is no great place for this, but the transaction api is
the primary place affected by this problem so I put the note there.
Closes: #2856
Approved by: alexlarsson
We need this to ensure that the dir can be shared with the new
system-helper flatpak user. Old dirs can happen to get less
permissions if there was a umask set when it was created.
Closes: #2856
Approved by: alexlarsson
Old versions of the create-usb command created a summary file in the
local repo being pulled from (e.g. /var/lib/flatpak/repo) but this
summary generation turned out not to be necessary and was removed. So
any computer which used the create-usb command before commit 7c5751a4f
will have a leftover /var/lib/flatpak/repo/summary file which becomes
outdated as apps are updated and installed. This causes problems for the
next invocation of (a recent version of) the create-usb command which
will use the outdated summary during the pull and fail with an error
message like:
error: Importing 3b1293596e9aa67f6fd0daeae477cb94603a4e8ca9e825f446d3dd04a2b5d5ec.commit:
fstatat(3b/1293596e9aa67f6fd0daeae477cb94603a4e8ca9e825f446d3dd04a2b5d5ec.commit): No such file or directory
So this commit makes the create-usb command delete the summary if it
exists before pulling onto the repo on the USB drive. This means USB
copies will work again for any users that used the USB app copy feature
in Endless OS 3.4.7.
Closes: #2854
Approved by: alexlarsson
When an appstream update is cancelled while downloading
icons, properly fail. Otherwise, the next update attempt
will see an up-to-date timestamp, think everyhing is ok
and not download the missing icons.
Closes: https://github.com/flatpak/flatpak/issues/2835Closes: #2836
Approved by: alexlarsson
flatpak run checks if there is any previous-ids for the app and
sees if there is a corresponding app-dir in ~/.var/app/ .
If so, it renames that app-dir to the new app-id and provides
a symlink from old app-id dir to new app-id dir, and exposes
these symlinks to the sandbox. The symlink is needed because even
though the XDG_DATA_DIR and other environment variables are set
to the new ID by flatpak run, the app itself could've stored
(eg in GSettings, or other files) paths which contained the old ID.
https://phabricator.endlessm.com/T23532Closes: #2775
Approved by: alexlarsson
end-of-lifed-with-rebase runs earlier in the transaction system than end-of-lifed, meaning it can modify the transaction for rebasing.
The new flatpak_transaction_add_rebase() function can then be used to apply the rebase if wanted.
Closes: #2775
Approved by: alexlarsson
With the new eol signal the list of ops can change during a resolve
operation, in which case we need to loop until things are stable.
Closes: #2775
Approved by: alexlarsson
When migrating an installed app from eos-apps to Flathub, it may have
had a different app ID (com.example.App) in eos-apps to the Flathub ID
(net.example.app). The migration logic arranges for previous-ids to be
set in the deploy file, and flatpak-dir.c preserves this across app
updates.
A user may have the app on their desktop or pinned to the taskbar under
its old ID, and the Shell uses X-Flatpak-RenamedFrom to update these to
the new ID. The migration logic arranges for the old ID to be added to
X-Flatpak-RenamedFrom at migration time; we need to also preserve this
across app updates.
Note that the Flathub version of the app may well have its own entries
in X-Flatpak-RenamedFrom. It is unlikely that these will overlap with
ours, but for neatness we take care to avoid adding duplicates.
https://phabricator.endlessm.com/T23845
Rebase 1.1.3 (T25194): Fix some minor merge conflicts
Closes: #2775
Approved by: alexlarsson
