FlatPak as a Software Source / flathub as a source of software


This is interesting because it contains some popular applications not available from any debian package repository.

Easy to setup on Debian.

Flatpak—the future of application distribution

It’s because flathub is already in Debian.

Debian -- Details of package flatpak in buster

Does flathub pass the TUF Threat Model, TUF: Attacks and Weaknesses [archive]?

Sandboxing abilities by flatpak are irrelevant as long as sandboxing isn’t worse as for manually installed software. Whatever sandboxing flatpak is doing, it shouldn’t break application’s own sandboxing. Such as, does flatpak break chromium’s own sandbox? I don’t know any indication for that yet. Just asking.

In other words, consideration is flathub as a source of software literally. It shouldn’t be held to a higher standard than APT.

1 Like

There have been no incidences reported of malware sneaking in past the code reviewers like snap so far. As for TUF security minded design, there’s no design documents I can readily find answering these questions so upstream needs to be asked. There is basic things like GPG signing all flatpak repo commits however.

For the Chrome package it seems they are running outside of the sanbox entirely otherwise it won’t work because of sandboxes conflicts.

1 Like
1 Like

The Chromium in flatpak has nested sandboxing - meaning it is patched to use both.

1 Like

Currently chromium or chromium based browsers doesnt work from flathub inside debian.

buster version of flatpak:

error: Failed to install org.chromium.Chromium: app/org.chromium.Chromium/x86_64/stable needs a later flatpak version (1.8.2)

When using buster-backports version of flatpak chromium still won’t work out of the box, but it is possible according to the following ticket.

Successfully tested just now.

Related to unprivileged user namespaces, kernel.unprivileged_userns_clone.

EDIT #1:

Reported to Debian.
org.chromium.Chromium broken in Debian buster

EDIT #2:

1 Like

nice tested on debian buster and its working as well. (but simon has nice reply which he gonna fix it without the need of security concerns in bullseye)

1 Like

On one hand, flathub seems like a great source of software for some cases. flathub’s own sandboxing capabilities even if limited forever could be disregarded for that use case.

On the other hand however, flathub’s own sandboxing capabilities interfere with other sandboxing initiatives, namely sandbox-app-launcher. Reference sandbox-app-launcher:

Could we request a feature from flathub to disable its own sandboxing to make it compatible with other sandboxing mechanisms such as sandbox-app-launcher?

Hello, Bug #977758 in bubblewrap reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: Stop making /usr/bin/bwrap setuid root (245de437) · Commits · Debian / bubblewrap · GitLab ------------------------------------------------------------------------ Stop making /usr/bin/bwrap setuid root With Debian kernels >= 5.10, this is no longer necessary: unprivileged users can now create user namespaces, the same as in upstream kernels and Ubuntu. For smooth upgrades, install a sysctl configuration fragment that will configure older kernels to behave similarly if the recommended procps package is installed. Closes: #977758 Closes: #977841 ------------------------------------------------------------------------ (this message was generated automatically) – Greetings https://bugs.debian.org/977758

Are they incompatible by merely running side-by-side on the same system or do you mean when they are sandboxing the same app we are?

You can set an override parameter to their sanbox:


1 Like

Incompatibility of anything by merely installing sandbox-app-launcher without using it seems very unlikely at this point. All that sandbox-app-launcher package does is a few dependencies (at time of writing sudo, bubblewrap, apparmor, libseccomp-dev, helper-scripts, dbus-x11) which by itself don’t do anything. Just extra files on the disk which remain dormant unless used by starting these / configuration of these. sandbox-app-launcher is essentially a wrapper around bubblewrap.

Yes. Ideally we could start a flatpak application through sandbox-app-launcher. I.e.

sandbox-app-launcher flatpak run org.org.Applicationname

Quote from this ticket:

No, the sandbox isn’t optional. You can only poke holes in it.


Extrepo may be a better alternative here. They have all the major browser repos in their curated list including the Chromium privacy fork Iridium and also a Torproject repo - which I haven’t checked yet but may be a more direct way to obtain newer TBB releases.

1 Like

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).