This is declared in the header file, but was never actually implemented.
Oops.
If anybody is hit by this issue, they can work around it by using
g_object_get() to get the FlatpakRemote:type property, which this is the
getter for.
Add it to the tests as well, so it gets exercised.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This takes a list of properties and generate finish arguments.
Additionally you can specify "bundle": true, which causes f-b to emit
an actual extension implementation, similar to e.g. the locale
and debuginfo extension.
Lookup extra-data files as
~/.local/share/flatpak/extra-data/SHA256/FILENAME, Similar to files
downloaded in the .flatpak-builder directory.
For now, if a corresponding file exists, assume it's the full download
and read bytes from it. Then proceed to do the same checks as for the
bytes downloaded by Soup.
In the future this directory could be used to support resumed downloads
by storing partial downloads.
Set up /var to $appdir/var binding after all the other filesystem
setup has happened. Before we did not do this, so a link from e.g.
/foo to /var/foo would be created in the appdir var rather than the tmpfs
var, which would fail with EEXIST the second time because that directory
is persisted.
In particular, this was problematic on endless os where /var/home is
a symlink.
This makes sure we always delete build dirs, even if there
was a build failure. This is useful for automatic build systems
like flathub or continuous integration.
This fixes https://github.com/flatpak/flatpak/issues/646
When creating a new commit of an app, we create deltas of it and from
its parent to it, and remove all other deltas. This can be problematic
during the switchover to the new delta, because some active operation
may be using the current delta when its deleted.
We fix this by keeping the parent and grandparent-to-parent deltas
around (but we never *generate* them).
Rather than a lot of #ifdef mess in the public headers, Alex would
prefer that the P2P API is made unconditionally public. This assumes
that they are unlikely to change in future. If they do, we just make
them return NULL or break API and drop them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Factor out the pull options which are common to the collection-based and
non-collection-based code paths. This should make the code a little
easier to read.
This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When the summary file is updated, it’s kept in a local cache, so that
parts of flatpak can refresh it at will without network impact. We need
the same for the ostree-metadata ref, which stores the repository’s
metadata when collection IDs and P2P are used.
Implement that by comparing the checksum of the ostree-metadata ref from
the summary file and from the local repository. If they differ, it’s
almost certainly going to be because the summary file is advertising a
more up-to-date ostree-metadata ref, which we should pull. If they don’t
differ, there’s no need to try and update the ref. Therefore, this
chains off the caching of the summary file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Use g_main_context_iteration() manually in a loop instead; this makes
the termination conditions more obvious. This does not change the
behaviour of the test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This adds variable support for collection IDs: they can either be
enabled on the server, on the server and client, or not at all. If
enabled on the server, apps and runtimes are built with collection IDs
and the repository has one set. If enabled on the client, the remote
config is added to the local repository with a collection ID and GPG
verification enabled. They are controlled with
USE_COLLECTIONS_IN_{SERVER,CLIENT}={yes,no}.
These variables are used in the new wrapper tests,
test-repo-collections.sh and test-repo-collections-server-only.sh.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add a sanity check and error message which prevents pulling the
ostree-metadata ref (the repository metadata) unless GPG verification is
enabled, as it needs to be signed to be trusted.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Emit an error message if the user tries to change the collection ID of
an existing repository between two non-empty values. Allow them to set a
collection ID where one was not set before. Changing the collection ID
once it’s already been set will break updates for all clients who have
previously pulled from the repository.
If a developer really wants to change the collection ID for a
repository, they’re going to have to recreate the repository from
scratch.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Emit an error message if a collection ID is specified but GPG is not
enabled, since pulling using collection IDs requires GPG.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This isn’t really used internally, but will be used by gnome-software
for when it configures new flatpak remotes.
This is new public API, but is only declared if compiling with
--enable-p2p.
Includes some basic smoketests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to provide a transition path for repositories to add collection
IDs to themselves and propagate those collection IDs to clients’ remote
configurations, add another repo config key which controls whether the
repository’s collection ID is published. If xa.collection-id is set in
the repo’s published metadata, the client will update its configuration
to the given ID — but only if no ID is set already. This is a one-time
transition to prevent malicious repositories from remotely changing the
user’s configuration to associate their remote with a well-known
collection ID they don’t own.
Add a test for this.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
To allow staged deployment of collection-ID-based repositories,
introduce the code to update a local repository configuration to add a
collection ID to it, based on updated metadata from the remote (as is
currently supported for other configuration keys).
As a security measure, this only allows updating the collection ID from
an empty to a non-empty value. We do not allow collection IDs to be
renamed (or a malicious repository owner could bypass the user’s manual
verification of the collection ID by changing it after the user has
configured an unrelated remote).
The idea is that most repositories should remain without collection IDs
for now, and use this mechanism to set their collection IDs in future,
once the functionality is more stable.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This will only be built when configured with P2P support. We can’t use
glib-mkenums here, as it doesn’t know about the #ifdef
FLATPAK_ENABLE_P2P which surrounds the enum definition. By manually
writing the get_type() function, we can surround it by #ifdefs as
appropriate.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than silently ignoring them. Note that invalid configurations
are distinct from missing configuration keys.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It can return FALSE with an error set, or FALSE without one set, which
indicates the key was not found.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When pulling from a local, untrusted repo (i.e. one which the user
downloaded into, and we want to pull into the trusted system repo),
verify the collection ID and ref bindings in the commit metadata for
each commit.
This is something which is normally done by libostree, but since we’re
rewriting the commit manually, we’re bypassing that part of the pull()
code path.
This is an inlined version of the check from verify_bindings() in
libostree.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add support for collection IDs to the code which finds and pulls
related refs and other extensions.
Currently, related refs must have the same collection ID as the parent
ref — this is the most likely scenario anyway. In future, it should be
possible to extend the code to support pulling related refs from other
collections.
Signed-off-by: Philip Withnall <withnall@endlessm.com>