For now, this just prints bits of summary information in
human-readable form. This command could grow over time
to provide other functionality for managing local repositories.
Show the same data the we show for other refs, when we
list extensions. In addition, show the subpaths if there
are any. Note that this reveals that the installed size
for subpath'ed extensions is misleading, since it is
the installed size for the full extension.
I have multiple branches of org.gnome.Platform install system-wide,
and non per-user. And flatpak info gives me:
flatpak info org.gnome.Platform
-> not installed
flatpak info --system org.gnome.Platform
-> multiple branches
This confusing behavior comes from the fact that we are querying
multiple locations and are not careful enough to collate the
errors we get properly. This commit changes things so that we
keep querying the next location as long as we get a 'not installed'
error, and we report the first 'multiple branches' error we get.
The --app and --runtime options are not really useful
for flatpak info, since you need to specify a full ID
anyway, and it is highly unlikely that you will have
ID clashes between apps and runtimes. Also, the options
are documented in a confusing way.
WAYLAND_DISPLAY can be other than "wayland-0" for various reasons, such
as using a custom Wayland display server or the session display server
using a custom display name.
Note that for xdg-desktop-portal to support showing portal windows, the
xdg-desktop-portal service MUST use the same WAYLAND_DISPLAY.
If branch is unset this is just a nicer way to set a
particular commit. However if both are set, then we verify
that the branch/tag is at that particular commit. This is
a nice way to document that we want to use a particular tag
but still protect against the tag changing or a MITM attack
modifying what that tag means.
gpgme is built with large file support by default, and checks that
its ABI (size of off_t) matches the ABI expected by library users
like flatpak. This caused build failures on Debian i386 and powerpc.
Signed-off-by: Simon McVittie <smcv@debian.org>
* Use ostree's BARE_USER_ONLY flag
Now that Ostree has a 'bare user only' mode for repositories, we should
use it.
This allows installing Flatpak run times inside different Docker layers.
Original patch by: Alexander Larsson <alexl@redhat.com>
Tested-by: Emmanuele Bassi <ebassi@gmail.com>
* Use the parent mode when creating a child repo
Instead of hard coding the repository mode, query the parent's mode.
* Gate bare-user-only repo creation behind an environment variable
We keep the default of bare-user repositories, but with an environment
variable we change new repositories to bare-user-only.
If you run "flatpak update" then we will never update to
a commit that is older than the currently installed one. This
protects against a man-in-the-middle attack that would otherwise
let the attacker downgrade to a previously signed version that
may have some vulnerability.
We never want the system-helper to downgrade. If you want to run
not-the-latest version you need to be "real root". However, the
check for this was broken, as it compared the new commit with the
new commit, which was always ok. Instead check the timestamp
on the new commit with the current one.
Sometimes we get an EAGAIN error in the due to the socket being
nonblocking. In the setup phase we just allocated the new buffer
and this causes a leak. Free it in this case.
The header returned from parse_header contains references
to the buffer it was used to parse from, and in some
cases we dereference these headers after freeing the buffer.
For instance this happens when we're filtering a message, and
then we later look at the destination to figure out what
kind of error to send back.
I couldn't find any cases where this would let the client
do anything other than return a different error value, but
this is still possibly a security issue.
The export g_autoptr changes in ostree will be in the release 2017.4,
but the gnome CI is currently failing due to them also being in current
git master which is called 2017.3 atm. We fix this by checking against
2017.3 instead, which is safe, because the actual OSTREE_CHECK_VERSION
macro was added after the 2017.3 release too.
Matthias Clasen