There are some changes needed to who automatic installation from OCI
repositories work that need to happen in the future. In order to not
"break" this support in a future stable release, we disable the adding
of oci repos unless the FLATPAK_ENABLE_EXPERIMENTAL_OCI environment
variable is set.
Previously we would still try to look up the remote information
to get the correct ref, this might not be supported in a case where
the user does not have an internet connection at the time that
applications are to be installed from the local repository.
Since flatpak can now install from *.flatpak and *.flatpakref files
rather than just remotes, show those files in the bash completion of a
"flatpak install ..." command.
Fixes https://github.com/flatpak/flatpak/issues/672
Many flatpak commands only work on *.flatpak or *.flatpakref files, so
the bash auto completion showing every file is distracting and
unnecessary. This commit makes flatpak only show relevant files when
possible by using the "-G globpattern" compgen option.
We no longer use bwrap --die-with-parent by default, because it has
problems due to the semantics of PR_SET_PDEATHSIG. In particular, it
will kill bwrap as soon as *any* thread in the parent exits, not just
the main one.
This caused weird problems in gnome-builder, as seen in:
https://bugzilla.gnome.org/show_bug.cgi?id=783950#c14
It should be safe to use this from single-threaded apps though,
so flatpak-builder can still use it. It just has to explicitly
enable it.
If a flatpakref has this set, for instance:
SuggestRemoteName=gnome-apps
Then flatpak install will ask if you want to configure
this as a "real" remote, rather than an origin remote (which
will only install that app).
This is useful when creating flatpakref files for remotes
that have multiple applications in them, such as e.g. flathub
or the gnome nightly builds. However, it should not be
set of one-application repositories.
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.
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).
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>
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>
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>
Newer repositories will store metadata there, rather than in the summary
file (although the summary file will still be updated where possible for
backwards compatibility).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to eliminate some race conditions around updating the
summary{,.sig} file on the server, and to decouple signing the summary
from signing commits, and to support peer to peer mirrors of content
from multiple upstream collections: add support for unsigned summary
files.
This relaxes the requirement for gpg-verify-summary=true iff
collection-id is set in a remote’s local configuration. It depends on
some pending libostree changes to verify the ref for each commit using
the commit’s signed metadata. See
https://github.com/ostreedev/ostree/issues/983.
Metadata storage has moved from the summary file to a new
ostree-metadata well-known branch on each repository, since this can be
signed for each update and for each collection separately. If the
collection-id is set in a remote’s local configuration, flatpak will
retrieve all repository metadata from this branch rather than from the
summary file. If collection-id is unset, it will ignore this branch and
continue to use the summary file, which will continue to be updated (and
externally signed as summary.sig) for backwards compatibility.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Search for updates on peer to peer sources as well as the internet in
check_for_updates(), and pass the resulting OstreeRepoFinderResult array
to the pull() calls, so a consistent set of checksums are pulled.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Resolver errors are more likely in offline remote adds than IO
errors. Catch them first when we're downgrading metadata update
errors to a warning.
https://phabricator.endlessm.com/T17172
Updating the metadata at the end of adding a remote means that it fails
if we're offline, even if we have the .flatpakrepo file available.
Unlike the other error cases in the process, which mean the operation
really has messed up, the remote is actually usable even if the
metadata update fails, because future operations will grab the
summary and any new metadata - so we should change this to a warning
to allow the operation to succeed when we're offline.
https://github.com/flatpak/flatpak/issues/917
Currently, all conceivable configurations and installations of
flatpak require root to perform this operation. That may not be
the case in the future, but until then, we should warn when the
user is not root as the operation will fail.
Fixes https://github.com/flatpak/flatpak/issues/855
The GLib logging framework automatically appends a \n to messages, so it
doesn’t need to be added by callers.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This makes it easier to avoid typos, and also makes it easier to see
what groups and keys are in use. In the header file, they are
clustered according to the group in which the keys are used.
Signed-off-by: Simon McVittie <smcv@collabora.com>
For example, add $(AM_CFLAGS) to mumble_CFLAGS. Since $(WARN_CFLAGS) is
only added to $(AM_CFLAGS), this fixes the lack of inclusion of the
compiler warning flags in the compilation of half of flatpak.
Note that $(AM_*) variables are only used by automake if a more specific
(per-target) special variable is not defined instead. So if you define
mumble_CFLAGS, AM_CFLAGS will not be used for that target unless
explicitly included in mumble_CFLAGS.
See
https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html.
Do the same for $(AM_LIBADD), $(AM_LDFLAGS), etc. These are not
currently defined, but it’s good practice to include them in
mumble_LIBADD (etc.) just in case they’re defined in future. Hopefully
their inclusions will be cargo-culted to any new targets which are
added, retaining full coverage of the code base.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The compiler warning flag which was supposed to warn about this was not
being included in the CFLAGS for these targets. That will be fixed in an
upcoming commit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There are several places which query keys in the metadata in the summary
file. Factor out a common function to do that, and write it in such a
way that it could be extended to read the metadata from somewhere else
in future (the plan being that metadata will move to an ostree-metadata
branch rather than the summary file).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Factor out a common GVariant child getter from all the print_*()
functions. This will make upcoming changes a little easier to integrate.
This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This canonicalizes the file modes for directories to 0755, and
for files to 0755 for executables or 0644 otherwise.
This means we never get files/dirs writable by non-root in the
system repo, and we never get setuid/setgid/sticky-bit, all
which could potentially be a problem if we store them in the
system repo.
See https://github.com/flatpak/flatpak/pull/837 for some discussion
about this.
Locale and Debug extensions, and refs for a secondary arch, when the
primary arch alternative exists, are not shown unless you specify
--all or -a.
This makes the default output more useful.
