* build-finish: Add --extension-priority option
This lets you set the priority of the extension.
* fixup! build-finish: Add --extension-priority option
* fixup! build-finish: Add --extension-priority option
In general libglnx has expanded a lot to have a good set of low-level wrappers
for things like writing a buffer to a fd. Also, we should use `O_TMPFILE`
if available - I think the code reduction speaks for itself here.
Writing this patch as a result of looking at what fds flatpak injects.
However, *really* we want to use sealed memfds. I'll likely copy the
systemd wrappers for that into libglnx too.
Also, it took me a while to figure out the reason the `--args` code
worked before was because we were leaking the fd.
(Updated by Alexander Larsson <alexl@redhat.com> to use O_TMPFILE
in more places, like for the seccomp code, and rebased on
some preparatory cleanups)
Closes: #1060
Approved by: alexlarsson
It's easy to end up with multiple flatpak installations on a system, and
it's not always clear which one(s) flatpak is using. So this commit adds
some debug output in some cases when flatpak opens an installation
directory such as /var/lib/flatpak. This is especially important for
people who build flatpak themselves because if you omit --prefix=/usr
or use --with-system-install-dir your flatpak will look in non-standard
locations like /usr/local/var/lib/flatpak.
If we were to print this every time a flatpak directory is opened, it
would flood the log. So instead add a utility function and use it
strategically. Many flatpak commands will log the directory when they
use flatpak_option_context_parse(), others in
flatpak_find_deploy_for_ref(), and for others the logging has been
added manually.
Closes: #1067
Approved by: alexlarsson
Instead of setting LD_LIBRARY_PATH to make the app load the right
libraries we run ldconfig to generate a ld.so.cache that we feed
to the sandbox as /etc/ld.so.cache. The cache itself is generated
by running ldconfig at run time, but for apps we cache the
result in $HOME/.var/app/$APPID/.ld.so/cache based on the
current app/runtime/extensions commit ids.
We also unset LD_LIBRARY_PATH, to ensure any host-side value
does not mess with the sandbox.
The default ld.so.conf we set (if the runtime has none, or an empty
one) is:
include /run/flatpak/ld.so.conf.d/*.conf
include /app/etc/ld.so.conf
/app/lib
Additionally all the extension points that have add_ld_path set gets a
ld.so.conf snippet in /run/flatpak/ld.so.conf.d.
This allows applications and extensions to install their own paths if
needed, and if the runtime wants more location they can install a
custom ld.so.conf that includes the above.
In the flatpak build case we still use LD_LIBRARY_PATH like before,
because there is no good key (like the commit ids) for keeping the
cache up-to-date. Also, the behaviour is different when building an
app for instance. If /app/lib is not in LD_LIBRARY_PATH then the
sandbox-wide /etc/ld.so.cache must be updated for a newly installed
library to work, but the sandbox is not allowed to update
/etc/ld.so.cache.
This code was originally written by Valentin David <valentin.david@gmail.com>
with changes by Alexander Larsson <alexl@redhat.com>.
Closes: #1073
Approved by: alexlarsson
A few fixes worth having, also just testing Homu.
```
Colin Walters (2):
fdio: Open target dirname for glnx_file_copy_at()
lockfile: Use an `initialized` member rather than explicit init
Jonathan Lebon (1):
macros: use size_t for glnx_strjoina len
Philip Withnall (1):
shutil: Fix assertion failure in glnx_shutil_mkdir_p_at()
```
Closes: #1046
Approved by: alexlarsson
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>
