Update all Templates over Tor

User Support
32

You can use Onion repository instead of clearnet, ensuring that you are using tor network.

dom0

  1. In dom0, open /etc/yum.repos.d/qubes-dom0.repo in a text editor.
  2. Comment out all the baseurl = https://yum.qubes-os.org/[...] and metalink lines.
  3. Uncomment all the baseurl = [...].onion lines.
  4. Update every .onion address to yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion . The affected lines should look like this:
#baseurl = https://yum.qubes-os.org/r$releasever/current/dom0/fc25
baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r$releasever/current/dom0/fc25
#metalink = https://yum.qubes-os.org/r$releasever/current/dom0/fc25/repodata/repomd.xml.metalink
  1. Open /etc/yum.repos.d/qubes-templates.repo in a text editor and repeat steps 2-4.

if the onion address is same as above, you don’t need to change anything, just comment / uncomment what it need.

Fedora TemplateVMs

  1. In the TemplateVM, open /etc/yum.repos.d/qubes-r4.repo in a text editor.
  2. Comment out every line that contains yum.qubes-os.org .
  3. Uncomment every line that contains .onion .
  4. Update every .onion address to yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion . The affected lines should look like this:
#baseurl = https://yum.qubes-os.org/r4.0/current/vm/fc$releasever
baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/current/vm/fc$releasever

if the onion address is same as above, you don’t need to change anything, just comment / uncomment what it need.

Debian & Whonix TemplateVMs

  1. In the TemplateVM, open /etc/apt/sources.list.d/qubes-r4.list in a text editor.
  2. Comment out every line that contains deb.qubes-os.org .
  3. Uncomment every line that contains .onion .
  4. Update every .onion address to deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion . The affected lines should look like this:
# Main qubes updates repository
#deb [arch=amd64] https://deb.qubes-os.org/r4.0/vm buster main
#deb-src https://deb.qubes-os.org/r4.0/vm buster main


# Qubes Tor updates repositories
# Main qubes updates repository
deb [arch=amd64] http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/vm buster main
#deb-src http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/vm buster main

if the onion address is same as above, you don’t need to change anything, just comment / uncomment what it need.

4 Likes
33

its to bad there isn’t a setting in Qubes Global Settings to change both dom0 and template updates to sys-whonix

don’t like to manually edit the sources file ; as simple as it is

34

You have to edit the sources file to use onion repositories, not to
update over Tor.

One reason not to have a Global setting for templates is because you may
want to use different update qubes for specific templates.

35

I think for this fresh 4.1 installation, I’m not going to pollute by manually changing repo sources.

someday if it was all in the QGlobalSettings, I’d trust I wouldn’t make a fatal mess or secure hole , ymmv :slight_smile:

like .onion sources for individual templates and Dom0 , built into the QGS tool

36

this post is from sept 14

is there any official maintained .onion addresses vs just changing global settings for dom0 to sys-whonix

which I imagine isn’t the same

37

The “official” onion repo addresses should already be in the .repo file, just commented out. You could simply comment out the clearnet lines and uncomment the onion lines. (Not sure if they’re really official. I believe they’re maintained by @unman.)

1 Like
38

I should mention that it’s not strictly necessary to use the onion repos. You can simply use the clearnet repos over Tor. You don’t get the usual onion service benefits, but to me, those aren’t very important for updates. I’d rather not have to worry about the onion mirrors lagging behind the official ones. But that’s just me.

1 Like
39

seems like qubes.UpdatesProxy in dom0
in 4.1 now just contains whonix-updatevm references

2nd line of $anyvm deny must mean all other templates use qubes-prefs updatevm choice ?

so to have templates use sys-whonix just change updatevm via $qubes-prefs ? Somehow I’m thinking that will only do dom0

so, is it in the documentation how to make templates use sys-whonix for their updates?(*other than commenting out sources.list.d in the template, which only includes the .onion addresses) if so where ? I’ll go look again

40

To be clear, I don’t maintain the onion mirrors. (At best I facilitate
them.)
Since they are included in the official repo definitions provided by
Qubes in dom0 and templates, I think they can be regarded as “official”.
The repository data is, of course, signed by Qubes.

As with any mirror there is a slight delay in the mirroring process.
Usually this is less than 4 hours - I believe the onion repositories
currently sync hourly.

1 Like
41

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

42

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?

43

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.

1 Like
44

Oh I see so connecting Templates to sys-whonix is considered “safe” enough rather than “none” and using the default ?

45

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:

  1. Route template updates over clearnet and use clearnet repos.
  2. Route template updates over Tor and use clearnet repos.
  3. Route template updates over Tor and use onion repos.

(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.)

1 Like
46

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 :slight_smile:

47

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
48

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.

49

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.

50

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.

1 Like
51

Answered here:

2 Likes