Flatpak apps

  1. Flatpak apps
  2. System-wide or per-user mode
  3. Routing all Flatpak apps' network traffic over Tor
  4. Repositories
  5. Persistent Storage
  6. Apps management user interface
    1. GNOME Software startup and update schedule
  7. Related pages

System-wide or per-user mode

Flatpak can operate in system-wide or per-user mode.

We set it up for the user in per-user mode for these reasons:

  • In system-wide mode, many operations (install, add overrides, repository configuration) needs privileges (not necessarily setting an administration password).
  • We install the Tor Browser pseudo-Flatpak as a system Flatpak, and we prefer to not give the amnesia user too much latitude to mis-configure it.

Routing all Flatpak apps' network traffic over Tor

Our research has shown that:

  • Standard environment variables, such as HTTP_PROXY and SOCKS_SERVER, are not honored by most Flatpak apps.
  • torsocks is not a viable approach either.

So instead we implemented transparent torification via the Tor's TransPort.

Repositories

We enable Flathub at build time by default, install the up-to-date GPGKey in the image, and keep its key up-to-date in Persistent Storage via on-activated-hooks.

Persistent Storage

Given the storage requirements, we only support managing Flatpak apps when the corresponding Persistent Storage feature is enabled.

That feature makes these directories persistent:

  • /.local/share/flatpak: repository data (configuration, keys, AppStream, icons...), runtime environments, the actual Flatpak apps, and overrides
  • ~/.var/app: user's application data (configuration, caches, etc.)
  • ~/.cache/gnome-software: icons and repository data cached by GNOME Software in its own format

Apps management user interface

We install GNOME Software with gnome-software-plugin-flatpak. We do not install gnome-software-plugin-deb: in Tails, GNOME Software is for Flatpak apps, while Debian packages are managed in other ways (APT on the command line, Synaptic as long as we ship it).

GNOME Software uses AppStream to get the list of apps available on Flathub: "AppStream is a metadata specification enabling software to provide rich, machine-readable information (screenshots, descriptions, versions) for app stores, including Flathub".

GNOME Software startup and update schedule

GNOME Software follows an update schedule by checking if certain conditions are met on its startup and every hour following that, and if met proceeds to fetch updates. The main condition is that it will only fetch updates if the last attempt for that was done another calendar day. It implements that by comparing the current time with a timestamp (org.gnome.software.check-timestamp GSetting) that was set last time it fetched updates (if not set it will also proceed). To benefit from this scheduling we make this timestamp (and GNOME Software's other settings) persistent as part of the Flatpak feature:

A wrapper for GNOME Software prevents it from starting if Tor isn't bootstrapped, informing users of this requirement. The reason for this is that GNOME Software updates the timestamp mentioned above even if started before Tor has bootstrapped so fetching upgrades will fail, and as a result all update checks fail for the rest of the day, so updates would only be fetched if the session extend far into the next day when the update check can succeed again. GNOME Software has a network availability check that will prevent the timestamp from being updated if there's no network, which prevents this issue in most normal cases, but not ours.

The service that starts GNOME Software is scheduled to start after Tor has bootstrapped:

XDG autostart is disabled, and DBusActivatable is dropped from the Desktop file to ensure that it executes the wrapper:

Related pages

See also: