Multiple Qubes-Whonix ™ templates
Multiple Qubes-Whonix ™ Templates provides much greater flexibility over a single template when choosing software packages. The additional cloned templates can be customized with software to meet specific requirements; something impossible to achieve with a single Template. 
- Packages from a later release: Installing packages from a later release could end up breaking the system. For example, mixing packages from Debian Stable with those of a later release like Debian Testing can lead to an unstable system because of associated software dependencies required for full functionality.   Prior to installing Debian packages from a later release, first read Install from Debian Testing.
- Custom software: Additional cloned templates makes it easy to install custom software used for a specific application. For example, users could Tunnel UDP over Tor by configuring
whonix-ws-16to route all applications through a VPN tunnel. However, this method also increases the risk of identity correlation. To mitigate this risk, the App Qube based on this template should only be used for the particular application that must be routed through the tunnel-link. Before installing custom software it is recommended to first read Install Software: General Advice.
- Untrusted packages: It is unwise to install untrusted packages in a template used for sensitive activities. With multiple cloned Templates, a single template can be designated as a less trusted domain for that purpose.  Read Trusting your templates prior to installing untrusted packages.
Note: Each Template's root filesystem runs independently from all other Templates.  Therefore, each individual Template must be updated separately.
Cloning templates in Qubes-Whonix ™ is easily accomplished via Qube Manager. Be careful with naming conventions for both Templates and App Qubes (based on those templates) so they are not confused with each other. This will minimize the chance of basing an App Qube on the wrong template.
When creating App Qubes based on cloned Templates, a purpose-based naming convention is sensible so there is no ambiguity regarding the intended function of an App Qube. For example, if an App Qube is created to tunnel UDP over Tor, appending
tunnel-udp (the purpose) to the end of
anon-whonix would lead to the name
To clone Qubes-Whonix ™ Templates, follow the steps below in Qube Manager:
Qube Manager →
VM to be Cloned →
Clone qube →
Enter name for Qube clone
When prompted, give the newly cloned VM a name that is not easily confused with other VMs. This minimizes the chances of basing an App Qube on the wrong template; there could be serious security concerns if a "trusted" App Qube was based on the wrong Template with untrusted packages.
Reminder: In Qubes R4 and above the NetVM setting of Templates should be set to
If you would like to change the UpdatesProxy setting for any Template, apply the following steps.
1. In dom0, open
/etc/qubes-rpc/policy/qubes.UpdatesProxy with root rights.
TODO: the following steps require testing.
2. Add at the very top of that file.
name-of-template-vm $default allow,target=name-of-proxy-vm
3. Save the file.
<Ctrl-X> --> press Y --> <Enter>
The procedure is now complete.
- Optionally, the default template can be cloned and used as the default template for App Qubes. Having a “known-good” backup template available at all times is best practice.
- Using packages from different repositories can lead to Dependency Hell.
- This problem can be avoided by cloning additional Whonix ™ templates and preferring packages from a single repository in each Template.
- It is strongly encouraged to only install signed packages from a trusted source.
- This applies to all Templates, even if they were cloned.
- Since Templates in Qubes R4 and above are supposed to be upgraded through qrexec based Qubes updates proxy.
/etc/qubes-rpc/policy/qubes.UpdatesProxycontains:$tag:whonix-updatevm $default allow,target=sys-whonixQuote:
Note that policy parsing stops at the first match, [...]