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.
The list of deltas is stored in the summary, so we need to delete
them before we generate the summary, not before.
This means there is a short period where people may use the old summary
which references the old, now deleted summaries. However, that is
better than it referencing the deleted deltas forever.
This makes it easier to reverse-map from commits to refs, for
e.g. statistics, but it also in the future will allow use to
not sign the summary and still use the system-helper.
This removes some duplicated code, and also follows the new
redirect-url property on initial add.
This also means we're requiring gpg signatures to be correct
on remote-add, so fix up the tests
I just saw a confusing error messages that looked like two error
messages just running into each other. Better to end the first
one with a colon when using g_prefix_error.
The underlying setters interpret NULL as 'unset this key', but
we never pass NULL. Since empty strings are not useful values
for title or default-branch or redirect-url, just interpret
an explicit empty value as 'unset this key'. E.g. to unset
the redirect url, use
flatpak build-update-repo --redirect-url= ~/my-repo/
Philip Withnall