Quoted, replied here just now:
Chromium Browser for Kicksecure Discussions (not Whonix) - #70 by Patrick
Should we install Debian -- Details of package flatpak in bullseye by default in Whonix 16 (Debian bullseye based)?
Would be useful to make installation of OnionShare from flatpak easier:
OnionShare Whonix integration development discussion - #23 by torjunkie
According to this (which wont fix, or at least anytime soon), Then our security complains from gentoo package manager are just the same as this one.
Better no, Stick to upstream.
This post is super difficult to understand for anyone but those knowing every bit of Whonix wiki.
This really could use a reference…
Security-Focused Operating System Comparison as Base for Whonix
I am not sure it’s worth rehashing the years old Gentoo stuff. Ideally any security argument against FlatPak could stay on itself without needing to refer to Gentoo anything.
I guess you mean this:
Install Additional Software Safely
Yeah so this is not suitable to be taken as a source of software until they fix this issue (Thats why i linked it to gentoo because of the similar issue in the package manager).
Any software delivery mechanism that is at least as secure as apt should be considered (if it doesn’t take up too much space).
Quote Whonix wiki flatpak Package Manager Security
Comparison by security features [34] (such as signed metadata) alone, flatpak package manager security is comparable to Debian’s APT package manager security with a caveat. Flatpak currently does not defend against
indefinite freeze attacks[archive].Definition of
indefinite freeze attacksaccording to theTUF(The Update Framework) Threat Model [archive]:Indefinite freeze attacks. An attacker continues to present files to a software update system files that the client has already seen. As a result, the client is kept unaware of new files.
This attack is difficult to pull-off for many adversaries since it requires breaking TLS. While flatpak package version information are not protected by a
valid-untilfield [archive] these are fetched over TLS. Even if an adversary could break TLS, this would be lesser of an issue torified connections (such as by Whonix ™) since the adversary could not mount a targeted indefinite freeze attack against a specific user. Only against all Tor users, which would likely be caught, unless the adversary also has the ability to break Tor. The attack chain would be very complex. Break Tor → target specific user(s) → break TLS → mount indefinite freeze attack → exploit vulnerability due to indefinite freeze attack caused outdated software version.To work around this issue, users would have to manually check if their version numbers of their flatpak installed applications match the version numbers available from the flathub repository. Every application available from flathub has a corresponding website has a chapter
Additional informationwith entriesUpdatedandVersion. For example for Chromium there is the org.chromium.Chromium flathub website [archive] which at the time of writing this wiki chapter showed.UpdatedDecember 23, 2020,Version87.0.4280.88-1. Since researching version information on the flathub website is equally vulnerable to indefinite freeze attacks as the flathub package manager itself (both rely on TLS), it is recommended to use Whonix ™ or Tor Browser for this purpose. [35]Sometimes versions available through APT are too old, even have known vulnerabilities being exploited in the wild, for a long time. (example) On the other hand, flatpak most of the time, offers more recent software versions and/or deploys security fixes in a more timely manner.
Due to the complex attack chain, the advantages of flatpak outweigh the severity of potential indefinite freeze attacks since flatpak is sometimes the only trustworthy, easy to use source of software (or never versions) than what Debian stable (with Frozen Packages) (or newer) is offering.
Some who criticized its provided security:
https://flatkill.org/ (2018)
Flatpak - a security nightmare (2020)
some who also discussed these criticisms:
We aren’t relying on flatpak’s sandbox so this is a moot point, but still interesting to follow.
EDIT:
TL;DR Summary of the post is: “it’s bad, but not that bad and they’re working on it.”
Unfortunately any flatpak package manager capabilities are overshadowed by any flatpak sandbox capabilities.
In comparison, APT does not attempt to sandbox any packages it installed. Hence, a lot less negative press about it.
Actually I might be better if flatpak and the sandbox would be separate projects so one project doesn’t inherit the reputation by the other.
But it pass TUF which flatpak fail as well to (fully) pass it. So not only sandboxing issue but as well on package level issues.
Similar argument to…
Refactoring default installed packages…
Should flatpak be installed by default on Whonix-Gateway? Usefulness? Some future hypothetical situation where flatpak might be useful to get a newer Tor version?
flatpak has quite some more dependencies than extrepo.
sudo apt install flatpak
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
The following additional packages will be installed:
fuse gnome-desktop3-data libappstream-glib8 libavahi-glib1 libgnome-desktop-3-19 libmalcontent-0-0 libostree-1-1 libpipewire-0.3-0 libpipewire-0.3-modules libspa-0.2-modules libstemmer0d
libxkbregistry0 p11-kit p11-kit-modules pipewire pipewire-bin xdg-desktop-portal xdg-desktop-portal-gtk
Suggested packages:
avahi-daemon malcontent-gui accountsservice evince
The following NEW packages will be installed:
flatpak fuse gnome-desktop3-data libappstream-glib8 libavahi-glib1 libgnome-desktop-3-19 libmalcontent-0-0 libostree-1-1 libpipewire-0.3-0 libpipewire-0.3-modules libspa-0.2-modules
libstemmer0d libxkbregistry0 p11-kit p11-kit-modules pipewire pipewire-bin xdg-desktop-portal xdg-desktop-portal-gtk
0 upgraded, 19 newly installed, 0 to remove and 1 not upgraded.
Need to get 3,438 kB/4,721 kB of archives.
After this operation, 23.5 MB of additional disk space will be used.
Do you want to continue? [Y/n]
sudo apt install –no-install-recommends flatpak
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
The following additional packages will be installed:
libappstream-glib8 libavahi-glib1 libmalcontent-0-0 libostree-1-1 libstemmer0d
Suggested packages:
avahi-daemon malcontent-gui
Recommended packages:
p11-kit xdg-desktop-portal xdg-desktop-portal-gtk | xdg-desktop-portal-backend
The following NEW packages will be installed:
flatpak libappstream-glib8 libavahi-glib1 libmalcontent-0-0 libostree-1-1 libstemmer0d
0 upgraded, 6 newly installed, 0 to remove and 1 not upgraded.
Need to get 642 kB/1,925 kB of archives.
After this operation, 9,062 kB of additional disk space will be used.
Do you want to continue? [Y/n]
I didn’t check yet which of the Recommends: would be actually be useful but useful for me without already.
Seems like overkill. No need to consider it unless Tor or its pluggable transports are not (easily) obtainable through any other means. Has to be officially distributed in this channel to even be considered, which isn’t the case AFAIK.
Possible long-term flatpak solution (particularly for Qubes-Whonix) based on 400 lines of code.
If you like it, it could be built and added as a default package in Whonix-WS in Whonix?
The steps below are functional, but you might have a cleaner method of doing it.
Tested to work with Signal Desktop as an example in anon-whonix-signal.
1. Clone anon-whonix to anon-whonix-flatpak.
2. Open a terminal in anon-whonix-flatpak.
3. Get the code.
sudo apt install git
git clone GitHub - micahflee/qube-apps: Install, run, and update apps without root and only in your home directory
cd flatpak-apps
4. Install Debian dependencies (fakeroot and build-essential are also required to build correctly in Whonix).
sudo apt-get install -y python3-setuptools python3-stdeb dh-python flatpak python3-pyside2.qtcore python3-pyside2.qtgui python3-pyside2.qtwidgets fakeroot build-essential
5. Build the package.
./build_deb.sh
6. Create a whonix-ws-16 clone called whonix-ws-16-flatpak
7. Copy the deb_dist folder (maybe only .deb required?) to whonix-ws-16-flatpak Template
Open Thunar file manager and navigate to the directory /home/user/flatpak-apps
Right-click on deb_dist folder
Select Copy to VM and select the destination as whonix-ws-16-flatpak
8. Install Qube Apps in the whonix-ws-16-flatpak Template
cd QubesIncoming/anon-whonix-flatpak/deb_dist
sudo apt install ./qube-apps_0.1.0-1_all.deb
9. Create a special anon-whonix App Qube for desired application. In this example let’s create anon-whonix-signal-desktop.
Make sure the whonix-ws-16-flatpak template is used when creating the App Qube and has all the other normal settings i.e. sys-whonix as NetVM.
Also increase the VM disk size to ~10GB so it doesn’t run out of space when later downloading applications with flatpak.
10. Launch anon-whonix-signal-desktop.
11. Add Qube Apps application to the App Qube menu under Qubes Settings → Applications, then launch it.
12. Search for “Signal”.
Click install “Signal Desktop” once it appears.
13. Once it has finished downloading, click “Run”.
After shutting down the App Qube, Signal can be easily run again or updated via this utility (or removed if necessary).
This means all that is now required for future flatpak apps is:
- Creating a new App Qube based on
whonix-ws-16-flatpaktemplate - Running Qubes Apps
- Searching for the desired application
- Clicking “Install”, then clicking “Run” once it has finished.
A lot easier than constantly stuffing around with flatpak manually, although obviously the flatpak application is in the App Qube, not the Template itself.
Overall, this package if pre-built and released as part of the Whonix build would be very useful IMO. 
Thanks Micah!
That’s more a feature request for Qubes, not (Qubes-)Whonix.
This is a GUI for flatpak? What’s the Qubes specific part? Perhaps it should even be contributed to flatpak instead?
Meanwhile as the companion blog post that you linked points out, this is already possible from the command line by using flatpak with --user. Then flatpak installs applications inside the user’s home folder. This is persistent among reboots in App Qubes as well.
Yes, GUI for flatpak.
Good point - should be made a Qubes package that is available across all distros. It would address a few things:
- bad usability at present for flatpak: users shouldn’t be required to rely on the terminal when possible. Annoying, painful, and easy to make mistakes.
- anyone complaining that XYZ version doesn’t work/doesn’t have the latest features can simply run Qube Apps, search for the package, install it in their home user directory in a cloned App Qube. Very simple.
- avoids manual update checks compared to when flatpak is installed on the command line i.e. they just click a button - “Check for updates” occasionally.
Whonix’s greatest weakness is poor usability & complex instructions for various tasks. If this can be avoided in certain cases - like this - then it should be embraced.
I’d create a Qubes ticket for it, but I don’t really play over there.