It will update the appvm, but all changes will be lost once you stop the appvm, this goes against the template architecture.
Yes I see that now as that script would only work if the flatpaks themselves was installed initially as --user. I wonder if there is a appvm script that can attempt to update the non --user flatpaks at boot although I doubt that as the appvm is so isolated from the template…
Defining a proxy globally for all software kinda defeats the purpose of template network isolation… Not that we ever actually had such an isolation in place, it is more security by obscurity.
Could you describe how it’s security by obscurity compared to having a network interface in your opinion?
1 Like
Because the network is instantly accessible, no matter if there is interface or not.
Back in the day, the proxy had filters to limit the targets that could
be reached. Patrick argued for their removal on grounds of usability. I
thought it was a mistake then and I think it a mistake now.
You can reinstate this control by setting FilterDefaultDeny in
tinyproxy.conf, and writing regex filters for the domains you want to
access. See man tinyproxy.conf.
If you use apt-cacher-ng you can restrict access to specific domains,
set in the main configuration file, and restrict access to specific
file types. See acng.conf for examples.
Both of these require manual intervention at the time you want to (ab)use
the proxy mechanism for anything other than updates. I think this is a
Good Thing™
6 Likes
Yet pretty understandable. Maintaining the ever-changing allow list with all the mirrors would be unfeasible. However, forcing a caching proxy could prevent anything that does not look like update packages from sneaking in.
1 Like
deleted
This setup does not work with the caching proxy. What do I have to install in the caching-template to make this work. (default is the debian-minimal)
I updated the guide to tell that exporting the variable for a whole user is a bad idea, and make it as an optional step with a warning. This was really not clear for end users, thank you both for insisting on this.
Could you describe what you did exactly?
Just followed you guide exactly and used this caching-proxy
Even if you export the proxy var, flatpak does not have internet. Have this issue on multiple machines.
Flatpaks work again if you set a different update vm.
Pretty sure the issue is that this proxy uses debian-12-minimal. No clue what software is missing tho
Or is this supposed to work and I made a mistake?
No idea, I never used this proxy.
You dont have to install anything in the caching template, but you do
have to configure flatpak to use the proxy.
I dont use flatpak myself (loathe it), but a quick search suggests
different methods to set use of a proxy - try them out until you find
one that works and then post that solution here.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
1 Like
please take a look at this thread. just a little bit of configuration makes it working.
1 Like
I am getting an error message:
Looking for matches…
F: An error was encountered searching remote ‘fedora’ for ‘example’: Unable to load summary from remote fedora: Failed to update OCI summary: While fetching https://registry.fedoraproject.org/index/static?label%3Aorg.flatpak.ref%3Aexists=1&architecture=amd64&os=linux&tag=latest: [6] Could not resolve hostname
Found ref ‘app/io.github.Dretch.MonomerFlatpakExample/x86_64/stable’ in remote ‘flathub’ (system).
Use this ref? [Y/n]:
Did you set the environment variable?
huh?
probably not since i don’t know what that is