Updates check over clearnet instead of sys-whonix and other strange decisions

So I just installed Qubes 4.2.2.

Before setting up everything I wanted to disable updates completely, because I didn’t want to advertise using QubesOS to my ISP.

First of all, it was impossible to actually choose “none” at the “Default update proxy” field at “Qubes OS Global Config”. The option is there, you can choose it, but it just not being saved, when you reopen Global Config you can see some other option chosen already.

I had to choose sys-whonix, at least I expected that nothing will try to update until I start sys-whonix, and I changed sys-whonix NetVM to “none” just in case it decides to autostart for updates.
Plus I chose “Disable checking for updates for all existing qubes”.

Then I made a couple of VMs, and soon I saw that they have updates.

It turns out that new VMs are automatically added as exceptions that receive updates.

Three questions I have:

  1. If it’s not a bug, why even make possible to choose “none” as Default update proxy, when it can’t be really used?

  2. Why automatically add all new qubes to exceptions, without even signaling to user, that it will happen? Isn’t it contradicts the very sense of “exceptions”?

  3. Why don’t enable updates check over sys-whonix when it is enabled for updates download? I found other people asking the same question on this forum without an answer.

It deeply disappoints me, because as I understand, even if I choose everything to update through whonix, it will still check for updates over clearnet.

So if you can’t hide that you use QubesOS anyway, then I don’t see realistic scenarios where updating over TOR make sense.

I do understand the importance of updating everything, but if devs wanted to go full Windows in this case, why even give user illusion of controlling such things?

3 Likes

Isn’t it possible to you in the Qubes OS Global Config GUI, in the tab “Updates” to choose sys-whonix as a default update proxy? This would make all updates to go through sys-whonix.

I may not have understood your requirements.

Turns out this only works for downloading updates, not for checking them.
As I said, giving the option to choose updates over TOR and not explaining, that it won’t help to hide using QubesOS from ISP anyway, is a bit misleading, in my opinion.
I’m sure many users don’t know about that. I can live with ISP now knowing that I use QubesOS, though before I spent some time in wane trying to conceal it.
But for some users this might be critical.

2 Likes

Checking updates is done within the qubes themselves indeed. This could be improved by using the according update proxy (there may be a reason it’s not done this way though).

Unfortunately, I don’t think Qubes OS is meant for the level of privacy you are looking for.

Well, thank you for your assessment, but since there’s nothing that suits me better, I have to deal with this anyway.

I wanted to start a discussion, not just to cry about it.

I believe that devs don’t read such things, but as I understand some people with access to them are reading and replying at the forum sometimes.

3 Likes

An ISP can track unencrypted DNS requests.
NetworkManager can be set to use encrypted IPv4 and IPv6 DNS requests through sites like quad9.
It appears whonix uses specific DNS servers.

A connection to yum.qubes-os.org is done to check updates, so there is not the DNS request alone.

The best solution is to use sys-whonix or a VPN as the netvm for the qubes you do not want to do anything on clearnet.

Related issue:

2 Likes

Agreed, even for general websurfing using a disposable, browsers like firefox can be configured to use encrypted DNS.

But it is inconvenient.
If it is really not possible/doesn’t make sense for the devs to make updates check through the whonixVM, it should be at least stated somewhere.
Because there is a special option to choose updates through TOR right from the installer, for me it looks like somewhat important part of QubesOS functional, but actually it is not so useful.
It’s like choosing update proxy that will work just in some cases and in others works something else, and you won’t know this when you choose it.

2 Likes

Would it make sense to change the text from “Update proxy” to “Templates update proxy”?

dom0 update proxy has a separate entry in the Global config GUI

How this would help?
As I understand dom0 update proxy works the same way.
Oh, it doesn’t have any netVM, maybe not.

Anyway, what would really make sense, is making at least an option of checking for updates through assigned (Templates) update proxy.

It would only help to avoid assumptions that the proxy is used for everything.

Oh, how well I understand you, dear friend! I created the topic with the same questions one day. :frowning:
I solved this problem like this:

  1. Disabed update checks for all qubes and added Whonix qubes as exceptions (and now have to always make sure that there did not appear any new non-whonix qube).
  2. Disabled networking for all non-whonix qubes.
  3. Set sys-whonix as update proxy for dom0 and as default update/whonix update proxy.
  4. Disabled clock qube for any case, because clock synchronization is performed through clearnet and this reveals that you use some Linux OS and also always highlightes when you’re connecting to the Internet with it. Otherwise who can say that you not just started Tor Browser on your android phone, using your current network?

Qubes devs really messed this moment, by doing everything the way they did. They confused the users by giving them false feeling that they can hide Qubes presence by enabling that whonix proxy feature. They could at least somehow explain in their docs what really must be done for this purpose or explain in installer how really works whonix update proxy feature in order do not confuse users by this, because as we know with you - hiding presence of such OSes like Qubes can be really important thing for many users around the world. :earth_asia: :pray:

1 Like

If a qube is trying to auto-update, run the following in the dom0 terminal to disable:

qvm-service -d <qube-name> qubes-update-check

This should be disabled by default, which one can verify with (should report as “off”):

qvm-service <qube-name> qubes-update-check

I also take the additional step of using .onion repos whenever possible so that attempted updates over clearnet will not be successful. I would also see these show up in my pihole filter, where all .onions are blocked, but I haven’t seen anything like this so I wonder if there was a recent regression that resulted in this behavior in new installs?

Not everything is SOFTWARE. There are TOR routers, servers, VPNs. After a few iterations with Qubes you’ll have legacy templates and VM’s. Parrot anonsurf use the script or some downloads. Really you are going to be pawn so many times… Maybe you’ll make it but most likely with these type of questions you’ll not.

This has always been an issue. I have deduced the devs want everyone to call home so they know how many users they have, at a minimum. What else it is used for, who knows. Not going to get fixed. In the past turning off in services had no effect - always had to run “systemctl mask qubes-update-check” in every new or cloned template as well as disable everywhere. When creating new qubes, in a standard config I disconnect the physical network until I can get updates disabled…

to check updates for each templates

they don’t need that as they already have information about Qubes OS usage through the Qubes OS packages repository for dom0. See Statistics | Qubes OS

1 Like

The OP issue has been bugging me for a few years as well. I noticed that even though I have set “Update Proxy” as sys-whonix in QubesOS global settings, so many times I noticed that I get “updates available” notification in the xfce-tray even though the sys-whonix wasn’t running (off, offline, shutdown). Imagine my shock and confusion.

2 Likes

Please feel free to open a bug report for this (if one doesn’t already exist).

It already does inform the user. In the screenshot below, it’s a red box containing a “red shield with exclamation point” icon next to text stating that it applies only to existing qubes and that new qubes will have update checking enabled by default:

(However, I’ve noted a problem with this.)

Probably because no one has opened an issue for it yet. I searched the issue tracker and wasn’t able to find one, so I’ve just opened one:

Not if you disable all update checks.

Updating over Tor has specific security benefits:

This is not accurate. For an accurate description of the situation, see: Privacy policy | Qubes OS

Surprised so many people have had a problem with this for so long, yet no one has opened an issue for it (at least not that I was able to find)! Anyway, opened one now:

4 Likes