Thank you all so far for the ideas and insights.
I’ve done a bit more thinking about general approaches:
- UpdateVM with Offline Caching: The most straight-forward solution would theoretically be to drop a caching program inside of the Qubes UpdateVM that catches all metadata and package files in a way that can be used for updating offline after shutdown/restart of the VM. Then one would just run an additional/clone online Qubes computer without holding any user data inside; run all of the Qubes Dom0 & Qubes Template package updates; have the UpdateVM catch/cache them inside of itself, then backup, transfer, restore this entire Qubes UpdateVM to the air-gapped Qubes computer; and then on the air-gapped Qubes computer run the normal Qubes update process through this restored UpdateVM with cached metadata and package files for all Dom0 & Template packages. Theoretically, the recommended more-secure “salt” based method of running Qubes updates should work with such an imported UpdateVM cache too.
I don’t know if such a Qubes-compatible UpdateVM caching program exists or not. Maybe rustybird’s “qubes-updates-cache” or unman’s “apt-cacher-ng” programs (linked below) could achieve this?
Regarding other approaches, here are some of my thoughts:
Running a Mirror Updates Web Server: I’m not familiar enough with Linux distro update authentication processes, but since many people/organisations create public HTTP update mirrors, then it should seemingly work to host the same type of HTTP update mirror on the LAN-network and point the Dom0 & Template repo files to the LAN-network IP address of one’s own update mirror web server. This seems to be the 2nd most straight forward solution. However, the cost involved would be the initial configuration and maintaining the web server setup that provides this mirror service between online and offline networks. Not a huge cost, but some cost, if a more ideal UpdateVM cache can’t be easily achieved.
Manually Scripted Downloader and/or Installer of Update Files: While this could seemingly work, this approach seems to have even more downsides and costs to it. Depending on the method of implementation, there may be a higher cost in the initial configuration/scripting setup. Additionally, my concern is with the security/authentication/verification of the updates. Experts might know how to manually process or script each step along the way without risk, but I don’t expect to become an expert in this subject matter any time soon. Potentially, a pre-existing script from a more knowledgeable expert would work fine here, and maybe some of the built-in protection mechanisms of Qubes, Fedora, Debian, etc would help to mitigate exploits upon installation of updates, but I know there have been several issues with update vulnerabilities that Qubes has even recently had to independently harden its update process against, so to not only rely upon Fedora/DNF etc.
Specific Personal Replies:
Brainhack - Thanks for your ideas. My thoughts on the general approach of your proposed solution are written above in the section “Manually Scripted Downloader and/or Installer of Update Files”.
ymy - Thanks for your ideas. My thoughts on the general approach of your proposed solution are written above in the section “Running a Mirror Updates Web Server”. Also, your concern about the security matter of the “salt” based method of running Qubes updates has been noted. Here is another Qubes forum discussion 4131 about that matter: Recommendation against "qubes-dom0-update" (use "Qubes Updater" instead)
@unman - Thanks for your ideas. Yes, your presumption of me having meant packages inside the templates is correct. Although, whole template updates would be an interesting optional extension too. I looked up some of your Qubes updates caching scripts (linked below). I haven’t tested them out yet and at first glance am not yet able determine how close they get to the more ideal UpdateVM cache I described. I have bookmarked them for further review/testing.
Existing Qubes Update Caching Tools Links:
qubes-update-cache by rustybird
Squid-based package update cache for Qubes:
apt-cacher-ng by unman
Using apt-cacher-ng as caching proxy:
salt-based apt-cacher-ng by unman
This is a caching proxy, based on apt-cacher-ng:
Any further ideas, insights, resources, are always appreciated!