Towards a Kicksecure template / understanding Qubes Updater mechanism

If a user attempts to onionize sources for a Standalone Debian vm and uses Whonix GW as networking for that qube then the following error will occur

So a Standalone qube will have to use Firewall for its networking. Torsocks in the Standalone qube will then be able to update from the onionized sources.

But what if you want your Debian template onionized? There is not yet a template for Kicksecure which is a hardened distribution morphing of Debian approved of by Whonix. Whonix updates from onionized sources successfully through the Qubes Updater mechanism, correct? So there must be an additional series of steps that must be carried out in order to update templates from onionized sources through the Qubes Updater mechanism if not through a Standalone with sources edited, tor transport installed, and tor running through the Qubes Firewall qube.

Centos, related to Fedora, has at least one onionized source out of SE. It would be interesting to see how Fedora updates would turn out if they were onionized. In principle, there is no reason why dnf(5) or yum couldnt update from an onionserver just like apt can (pacman also has onionized sourcing as an option), is there? There also must be a reason why Fedora is not so interested in onionizing.

Since updating a template directly is discouraged because that makes Dom0 vulnerable, what is the best way to onion update an VM OS? An onionized Debian Standalone, for instance, will still derive from a non onionized Debian template.

I have a few debian standalones with onion repository only.
You need to do the following to be able to do it (dom0):

  • Add updates-proxy-setup to your qube: qvm-features qube service.updates-proxy-setup 1
  • Add the whonix-updatevm tag to your qube: qvm-tags qube add whonix-updatevm

Reboot if your qube is running, then you will be able to update using any onion repositories without using tor+ with them.

1 Like