This is a new version of --deploy-collection-id that only applies
the collection id update for new (1.7.x+) version of flatpak clients.
This allows you to enable collection ids for sideload use but not
affect older clients where the p2p codepaths are not as tested.
This used to not be set for collection-id remotes as we used the
ostree-metadata branch for resolving. However, we now use the summary
always when doing a remote install (and not ostree-metadata for local
sideloads), so we still want to verify summary.
The signature on the summary is a nice security feature, but it is also
a very efficient small file to download to verify that no new summary
needs to be downloaded in the no-op update case.
* Test that we load from sideload repo even when online
* Test that when offline we don't update to older version in sideload repo
* Test update to explicit version in sideload repo
* Test updates to new version from sideload repo
Nothing fundamentally happens differently in ostree if the collection-id
is set, as long as we don't call the p2p specific apis. So, lets keep
using it instead of adding our own special magic.
With the new sideload approach to collection ids it is fine to require
gpg signed summaries. (Not for the child repos or the sideload repos
though, but thoser are either trusted (sideload) or safe for other
reasons like ref-bindings and signed commits).
We used to to do a MIRROR pull and make a copy of the upstream summary
file in the child repo. However, now that we want to allow side-loading
from a repo with a partial summary we can no longer do that.
So, the new approach is that the child repo *always* contains
"remote:ref" style refs (never heads or mirror/collection-id refs),
but in order to not let you import a signel commit into the wrong ref
name we now require the commits to have a ref-binding (they all do
since a long time anyway).
Most code that looks for a regular collection id set on the remote is
removed, as these should never happen in flatpak repo setups now.
Some is replaces with looking at xa.sideload-collection-id:
* The libflatpak FlatpakRef::collection-id property now comes comes from the sideload id
* Various CLI commands showing or changing the collection-id for a remote now uses the sideload id
* Collection id deploy in update now sets the sideload-collection-id instead
* Setting the collection id for a remote in libflatpak now sets the sideload id
Additionally we now delete the code that allows unsigned summaries
when there is a collection id (because there is none).
create-usb now uses the sideload id as as collection id source when exporting.
The direct repo operations (export, bundle, commit-from) still support
collection ids, because on the server we do want to set it so that we
can sideload.
This adds a xa.sideload-collection-id option to the remote
configuration and a global xa.sideload-repos option (which is a list
of paths to local repos).
When resolving or listing refs, if we fail to download the real remote
summary (i.e. we're offline) then we instead look into the configured
sideloaded repos for refs that match ref and the sideloaded collection
id for the remote.
For the transaction to resolve the ref we need more metadata. In the
regular summary case we use the metadata from the summary, but that
is not available in the (partial) summary in the sideload repo, so
there we load the actual commit object and use the data from there.
(The ostree-metadata branch is not used/needed.)
This actually also fixes a longstanding issue when you "flatpak update
--checksum=XYZ" because we now handle this correctly by downloading
the commit object from the remote. Before we used the metadata in the
summary which is not right for non-HEAD commits.
To handle the sideloading we record the path to the sideload repo
when sideloading and pass the url to the repo as the remote name
when pulling, which will do a direct local pull.
We avoid using sideloaded refs when offline if the timestamp in the
commits is older than what is already installed locally.
This removes the most basic codepaths for p2p installation, as well
as the tests for it. There still remains various codepaths that
looks as the collection id, these will be removed later.
This is the first step in dropping the p2p code and replacing it with
a simpler approach that focuses on the sideloading case only.
We're using the metadata from the summary, ostree-metadata or available
commit when making security sensitive decisions, so lets verify this
matches what we get in the actual commit we pulled.
We already did check that this then actually also matches what gets deployed,
so the new check shares code with that.
Note, we don't do this for OCI installs, because it seems the current
fedora flatpaks don't have this set, and we don't want to break
existing remotes.
Currently if flatpak is installing an extra data app such as Spotify and
the server with the .deb file fails to complete the request, the
installation fails with a message like "Connection terminated
unexpectedly". This commit makes flatpak instead try 5 times to download
a given URI if the error returned seems like a transient one (so not,
for example, 404 not found). This is analogous to what was done in
libostree in commit 938055392fd455027a69398c441b992ae521aa87, and we use
some code from there.
We use some BASH_XTRACEFD hackery to hide the trace output from
the internals of the assert (and ok) functions, so that the
log output can focus on what is important, i.e. what asserts are
checked and what errors do they print.
Allow the app-id or the DConf path to finish with a digit and still be
considered similar enough for DConf migration purposes.
This allows the org.gnome.Rhythmbox3 app-id to migrate its
/org/gnome/rhythmbox DConf path.
See https://github.com/flathub/org.gnome.Rhythmbox3/pull/26
When we already have a token for the first repository after probing
for no-auth authenticator or testing user-entered credentials, just
use that, don't request it again in the loop over repositories.
This gives a significant optimization of the prompted-credentials
case for registry.redhat.io, which takes 4-5 seconds to generate a
token, hopefully avoiding the user thinking something has gone wrong.
Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
Fix problems overwriting a GError when we retry multiple times.
One of these was introduced with the recent change
e3f17a89a flatpak-oci-authenticator: try getting a token without credentials
but the other was existing.
Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
flatpak_bwrap_bundle_args() for some reasons does:
data = g_new (gchar, data_len);
*data = 0;
And then it starts copying in the data into the allocation, overwriting
the initial 0. If data_len is 0 this causes a write past end of
allocation, so just drop the second line above.
When storing the token-type in the commit and the summary cache we
hardcode it to little-endian.
In theory this breaks the "ABI", but in practice this change is a
no-op on little-endian systems which is what most are. Additionally as most
servers are little-endian this also fixes using big-endian clients with
such servers.
This fixes:
https://github.com/flatpak/flatpak/issues/3434
New users who jump directly into this command might think this command is to init a project or application dictionary but it actually creates somehow a directory for *built* app to run inside.
plus, fix not working example
Sorry for such minor and boring commit.
If no scope parameter is supplied in the WWW-Authenticate header,
docker and libpod will make up their own of the form
repository:<reponame>:pull when requesting a bearer token. Match that.
Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
