Best practices for installing Flatpak/Snap/AppImage packages in Qubes?

What are the best practices for installing Flatpaks (or Snaps, or AppImages) in Qubes? In particular, where should they be installed?

Installing Flatpaks in a TemplateVM requires enabling networking in the TemplateVM, which could be a security risk. As far as I know, Flatpaks are signed just like regular packages, but I believe the risk here is having all the networking code running in the TemplateVM. Do you think this method is safe “enough” for most people?

Another option is installing Flatpaks in AppVMs, either in user-mode, or under /usr/local. There are a couple of downsides to this. This method is fine if you’re only using them in a few AppVMs, but it’s inconvenient if you want to install and update the same Flatpaks across many AppVMs. The other downside is that Flatpak must use the same NetVM as the rest of the apps. This is a problem if you want to proxy updates over sys-whonix, or if the AppVM is offline or its firewall blocks Flatpak from accessing the internet. For example, I have several AppVMs whose firewall only allows access to the local network, but they are updated in the TemplateVM via the updates proxy.

Finally, in a StandaloneVM, Flatpak should work pretty much the same as regular package managers, along with the same drawbacks of course.

If there were a Flatpak proxy that used the existing UpdateProxy policy, it would potentially solve all the above problems. It would not only allow Flatpaks to work as expected in offline TemplateVMs, but if the proxy were also accessible from AppVMs, then Flatpaks could be installed and updated within AppVMs and StandaloneVMs regardless of their firewall or NetVM settings. Unfortunately, no such thing exists yet.

Does anyone have any experience or recommendations about this?

One question worth bringing up (I think) is the update process, namely the integration of the update mechanism with Qubes. If the update is not as trivial as clicking update on the Qubes Updater, people will probably get lazy and forget to update software (I’ve been there myself). So without a reliable update mechanism it can be an extra security liability.

I’d appreciate thoughts on best practices also. What I’ve done so far:

AppImage: Installed in AppVM. Download via DispVM and then move to desired AppVM. As I understand it, AppImages are basically complete executables, so I wonder about signatures, safety, etc.

Flatpak: I have a debian-flatpak template based off Debian Minimal with networking & flatpak installed. Actual flatpaks are installed only in AppVMs based on this template - each in user mode in its own AppVM. Again, not sure about signatures, safety, etc.

Snap: Haven’t done.

So far, I don’t have your need for these apps in multiple VMs, and have only used Flatpaks that were for Internet use anyway… I don’t have many of these, and so updating manually is fine so far.

I thought about this too. I’m not exactly sure how the Qubes Updater is implemented, i.e. with respect to disp-mgmt-*. I would think that as long as Flatpak/AppImage/Snap supports separation of the download an install operations, it probably wouldn’t be hard to adapt the Qubes Updater to it. It already somehow supports two different package managers (apt and dnf) so adding a third shouldn’t be all that hard. I’ll have to read up on it some more.

Thanks for your input! That would probably work for me. I haven’t actually tried AppImage at all yet (inside or outside Qubes), so I’ll definitely give it a try. I thought about offline installation with Flatpak too, but it’s not exactly straightforward. It sounds like AppImage is better suited for this.

At the moment I wouldn’t really need them to be shared across VMs either. I just brought it up because it would be nice to have that option, but right now I can’t think of any package I would need in a lot of different VMs. The networking part is a bigger problem for me, as some of my VMs don’t have internet access.

A NetVM isn’t actually required for installing just Flatpak itself, is it? It’s only when you enable a repo or install packages that it needs to be online?

This got me thinking… I wonder if simply qvm-copying a user-mode installed Flatpak could actually work. If so, I could setup a dedicated AppVM with appropriate networking for installing and updating Flatpaks, and then have a script copy the packages into the more restricted AppVMs where they’ll be run. It wouldn’t be very pretty, but it would be safe and automated then.

I would hope they’re using signatures and everything like you’d expect from any package manager in this day and age. Then again, last time I checked Gentoo and several other distros were still downloading unsigned packages from random mirrors over insecure http, so I guess you can’t be too sure.

Sorry if I wasn’t clear. Correct - the Debian template does NOT have a NetVM. Only the AppVMs have NetVMs. Since the Flatpaks I use are all for Internet purposes, the AppVMs having NetVMs was a given, and are used to get the Flatpaks.

@Cappire This is also the way I’d do it. You can also verify the AppImage on the DispVM and then move to the desiredAppVM.

Then don’t forget to create an icon for it in /user/share/applications/ so it shows up in the Qubes menu.