The mechanism has changed in 4.1 - this is a hangover.
You should look in /etc/qubes/policy.d
The default policy file is 90-default.policy.
You will find the updates policy there.
If you want to change the defaults put the new policy in (e,g)
30-user.policy
I can use the QGlobal Settings to change dom0 to use sys-whonix ,
but ADW mentioned updating Templates over sys-whonix, but Not using .onions ;
was curious how that is done
and/or if it is outlined in the documentation somewhere?
If you connect through Tor then you can connect to the normal repositories.
That’s fine. It’s probably what most people do.
You can also change the repository definitions in the apt/yum repo
sources files to use onion addresses. Then you connect through Tor to a
hidden service.
Oh I see so connecting Templates to sys-whonix is considered “safe” enough rather than “none” and using the default ?
Let me see if I can try to help clarify.
If I understand correctly, you are asking about setting the NetVM of a template to sys-whonix. That is not what @unman was saying, and you should not do that. Templates should remain on default (n/a) as their NetVMs (which I understand to be the same as none).
Rather, when @unman says:
He’s referring to setting the UpdatesProxy to route template updates over sys-whonix rather than sys-net. In other words, in /etc/qubes-rpc/policy/qubes.UpdatesProxy in dom0, this line (or the functional equivalent, if your version uses different syntax) would be at the top (or at least not below any template sys-net line):
# Upgrade all TemplateVMs through sys-whonix.
@type:TemplateVM @default allow,target=sys-whonix
Notice that the second line is uncommented. Again, this line should be above any sys-net rule in qubes.UpdatesProxy if you wish to route template updates over Tor (using sys-whonix).
With this setup, you will be routing all template updates over Tor. However, if you have not changed any other defaults, you will probably still be using the normal clearnet repos over Tor, which is fine.
This is the further change that results in both routing template updates over Tor and using the onion repos.
To summarize, there are three possibilities:
(Note 1: It’s not possible to route template updates over clearnet and use the onion repos, because the onion repos can be accessed only within the Tor network.)
(Note 2: I’m speaking only about template updates here – and not any other types of updates – to avoid muddying the waters.)
except in 4.1 is it now
/policy.d
and in sum too dangerous to touch IMO
thanks though, even in 4.0.x though I might make it work might also mess it up manually editing, very clear write up though 
I selected update over Tor during the installation, however, the updating is too slow. I want to do the opposite, namely, to revert back to update over clear net.
I have the following in qubes.UpdateProxy
$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm $anyvm deny
Shall I add the following?!
# other templates use sys-net
$type:template $default allow,target=sys-net
$anyvm $anyvm deny
policy files have changed - you can get the desired result by deleting
this file completely.
The default policy is set in /etc/qubes/policy.d/90-default.policy which
sets these policies using the correct syntax.
Apologize for the general question, but what specific threats can be addressed by having tor updates over TOR? What threat model does this address? The most I can think of is that an attacker can’t see in local traffic what updates a person is downloading.
I’m not clear what you mean by “tor updates” in this context.
The advantage you have cited is one benefit.
Another is the general advantage of using Tor, that it is not so easy to
pollute DNS, and control the target repositories.
Answered here: