Every time I create a Standalone, Qubes Updater is unable to update the new qubes and the only way to update is directly through the qube terminal. But this is bypassing “security measures.” What are those exactly? Why isn’t this working and how do I make Qubes Update work for all new qubes?
“not recommended, since these bypass built-in Qubes OS update security measures. Instead, we strongly recommend using the Qubes Update tool or its command-line equivalents”
how do you create the standalone?
Qubes Manager → new qube
do you make them in Dom0 terminal? Is there a difference?
I’ve had Standalones update fine before. Then spontaneously something is obstructing updates over tor.
How do the attackers disrupt Qubes Updater updates over tor for package metadata spying?
failed to refresh Inrelease deb.debian
temporary failure resolving deb.debian
failed to fetch deb.qubes-os
Is it a standalone based on a template?
Post the standalone update log from the Qubes Update tool.
And also post the output of sudo apt update in this standalone’s terminal.
I may share the “logs” later (there is even a button for that) but I don’t think that will provide any information that will be useful to solving this issue (and the uninformed audience thinks that any information shared makes one inferior and subjugated to search).
The attacker wants “non-dominant” updates, which means: just screwed off because you are not an IW as if everything in the internet can be accessed through tor. It cannot.
But how are updates over tor blocked? VPN and DNS still work. But then they just declare screwed off because they can get metadata supposedly unlike tor (supposedly, but these are global surveillance actors).
Perhaps the tor network itself or software communities have a upstream su of some sort.
I have seen VPNs and ZTNA (as well as tor) function as an attack vector. VPNs are not “open” to just any one small town cop. There are Engineering firms whose “insider” employees work remotely, CISA, and FBI agents who are supremely well acquainted with how the technology works.
Standalones used to network with Whonix GW just fine. What changed?
Now, when I try to make a Standalone of Whonix WS, it is not allowed. A clone Whonix WS app vm will update and install packages over onion repositories (edit /etc/apt) but root is volatile. Only standard Whonix apps are able to be stream isolated with onion repositories?
[FYI. The attackers also damage their victims IRL. That must be why they want metadata: to target specific developers and maintainers. They cause–among many excruciatingly painful and damaging physical injuries–wasting disease because they think they are “core dumping” their targets bodily. Their MO is an unsightly mixture of superstition and crude analogy combined with technical expertise.]
Does anyone think adding Vanguards to a Whonix GW might help?
It’s concerning that Debian and thus Tails and Whonix do not support full vanguards protection for Tor. Arti does support full vanguards though.
Necro.
I had assumed that Whonix would be using Tor from source, rather than
through Debian’s package.
In any case, vanguards is in forky, so you could pull it in from there,
if you are in need.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
You are a Saint, thanks that is exactly what I needed.
Arti tor with full vanguards is highly effective against an actively hostile ISP. Whonix downloads have failed me over the last few weeks of intense targeting, but if a bad packet gets sent to Arti that tries to manipulate the time or session rust blocks it and the download works. Tested on ourtea 2.4 
How are you using Arti? Do you have a gw?
