There is an open Github Issue on their repository from 2018 with tonnes of support, but despite this, the Mullvad team is small and doesn’t have the bandwidth to focus on it. I’m posting here, hoping someone who enjoys packaging can take a look at this and get the VPN up and running on Flatpak
PS if anyone wants to give this a crack, DM me for a free Mullvad key
Edit: Someone seems to have gone through my post history and flagged all my threads/comments - The system is telling me to edit my comment to make it reappear, so that’s what this is
This is still flagged for some reason, possibly because you’ve offered a “financial contribution” as reward and someone might’ve thought it was spam.
In any case, this is a legitimate request and I’d like to have the application packaged as Flatpak as well, it’s not working correctly on Silverblue due to a weird directory layout and SELinux issues.
If I have some spare time I might give it a try, but no promise yet.
I’ve done some exploratory research on the feasibility of wrapping Mullvad into a Flatpak and I don’t think it’s possible at this time.
The fact that it requires host network access is the least of our problems, as it should be easy to give the sandbox access to the host network namespace.
The big issue instead is that the desktop application relies on a system-level daemon that can either be configured to start at boot, or the application manages itself when you start or stop the VPN. The GUI is just a shell that talks with this daemon via RPC: mullvadvpn-app/architecture.md at master · mullvad/mullvadvpn-app · GitHub
With flatpak there is no way of running background daemons, which would break the “start VPN at boot” option, and the fact that Mullvad expects to interact with this daemon through systemctl, which isn’t available inside the sandbox, pretty much makes it impossible to be packaged as it is, without major changes upstream.
Sadly, Mullvad has said many times they do not have the bandwidth to explore alternative configurations than the standard .deb and .rpm they provide so unless someone has the patience of rearchitecturing their application and getting it approved and merged in the first place, there’s not much we can do.
You are confusing access with control. Flatpak can have only the former. The latter needs system level daemon. You made same conclusion as mine without realizing it.
Flatpak can sort of run background daemons, but it requires --devel permissions which makes the sandbox security a joke. We use it in the opencpn project for some plugins which provides DRM stuff using a binary blob running in background.
Of course, if the daemon must run as root I don’t think it would be possible at all.
