Correct. Can you make head or tail of it what files are / have to be modified and how?
Not really! 
But I’ll tell you one thing that doesn’t work (someone had to be the guinea pig). Re:
Probable workaround solution:
Just delete sys-whonix, rename the sys-whonix-clone to sys-whonix & reboot.
Result is:
- the clone which was renamed to sys-whonix doesn’t boot automatically (but you can start it manually after hitting the normal Qubes desktop).
- when you try to run dom0-updates over whonix, you get the message “UpdateVM not set, exiting”
- this is fixed by:
qubes-prefs --set updatevm sys-whonix
-
templateVM updates still work, including over .onions
-
GUI templateVM settings don’t show the current NetVM actually in use, but an incorrect value. But when you scroll up, you can see it is all still all configured properly with the “(current)” tag set to all the right VMs.
So, in short, not recommended. Obviously sys-whonix is much harder coded than some renamed clone with an identical name…
Anyway, this is a big problem as it stands now i.e. if a Qubes-Whonix user has a sys-whonix that becomes corrupted, or simply won’t bootstrap, ever, then they have to do a lot of manual fiddling on every reboot.
Reason: because their brand spanking new sys-whonix either won’t boot automatically, or if they kept the old one, it will always boot, not matter what VM settings they change.
The fact this has never been mentioned tells me that not a single person has every rotated their sys-whonix in the community. That’s an awful lot of trust they’re putting in its integrity over many months.
1 Like
Theory: Create a VM and set it to autostart. Clone it. It won’t inherit the autostart property. Could you please test if that is true and then open a bug against Issues · QubesOS/qubes-issues · GitHub if that is unexpected behavior?
When you delete the VM which is currently set set UpdateVM, what would you expect to happen? To keep the setting at the now non-existing setting?
To regenerate sys-whonix, is there a way to regenerate its private image? @marmarek
Or perhaps you delete sys-whonix and then just re-run all the salt grains to have it re-setup for you?
Do you know, TemplateVMs are now non-networked in Qubes R4? SO I would expect it to be set to none. Right?
It requires disabling autostart for sys-whonix as well as to not set it as NetVM for any other VM to prevent it from being autostart.
Didn’t realize there was real discussion happening in this thread…
I’ve played with autostart a lot in Qubes 3.2.
- My gateways have never been named
sys-whonix. - I have multiple gateways configured but only one autostarts.
- IIRC any VM that is set as a default in Qubes Global Settings will autostart as well as any VM that is dependency of another autostart VM.
- To prevent
sys-whonixfrom autostarting it must be disabled as a defaultVM in Qubes Global Settings (including updateVM, netVM, clockVM, etc). It must also be set to not autostart in VM Settings and no other autostart VMs can depend onsys-whonixin their netVM chain.
Related: One recommendation that should be made with respect to templates: If space allows, never use default downloaded template. This is especially true for whonix-gw & whonix-ws. They should always be cloned first. This ensures that you have a clean template to fall back on. Also, when Whonix-14 comes out, you can upgrade the downloaded template without affecting any existing Whonix-13 templates (ie you can have them side-by-side to ease migration). (Shouldn’t Whonix templates be named as whonix-13-gw, whonix-14-gw, similar to fedora-25, fedora-26, etc?)
I’m not convinced of the necessity of having a disposable sys-whonix / sys-whonix rotation. I think sys-whonix is an order of magnitude safer than say anon-whonix or sys-net. If sys-whonix rotation is going to be recommended then I think it’s important to safely / easily migrate persistent Tor state.
Most of the info regarding entry guard selection is outdated. Here are the proposals implemented in:
0.2.9: 236-single-guard-node.txt\proposals - torspec - Tor's protocol specifications
0.3+: 271-another-guard-selection.txt\proposals - torspec - Tor's protocol specifications
Haven’t had time to study them but clearly a lot of thought has gone into the process - which we would be throwing out by discarding state.
1 Like
Could you review Data Collection Techniques: Difference between revisions - Whonix please? @HulaHoop
This is a massive edit. I’ll try and get around to it when I have time, if anyone wants to jump in please feel free.
A general impression I have is that its too much info overload, It overwhelms users without much benefit. The average joe doesn;t need to know the life story of cookies, when they were born or who created them. Referencing parent articles and papers would have been enough.
1 Like
HulaHoop:
This is a massive edit. I’ll try and get around to it when I have time, if anyone wants to jump in please feel free.
A general impression I have is that its too much info overload, It overwhelms users without much benefit. The average joe doesn;t need to know the life story of cookies, when they were born or who created them. Referencing parent articles and papers would have been enough.
It’s true. I don’t know what I thought when I originally imported that
documentation page from JonDoNym in 2013. 
It was along the lines
“complete Whonix documentation”, “do at minimum what other projects do
and go beyond that”. It’s a good question, what is within the scope of
the Whonix project and what’s out of scope. We don’t want to bind too
much scarce team time for review/maintenance of auxiliary subjects.
Whonix already scaled beyond what I can reasonable keep up with.
In comparison, there is Template:Maintainer:
https://www.whonix.org/wiki/Template:Maintainer
Which is used by a few articles listed here:
Like the article Nymservers is only maintained by @HulaHoop.
I refuse to fully understand and answer support inquiries about it. Or
to review significant changes. Only the maintainer @HulaHoop will do. I
see it as a piece (of non-controversial) free speech by @HulaHoop. Yet,
it doesn’t harm having it hosted on whonix.org. It’s even cool since
it’s Libre Software, contributing to Whonix generally, and useful to
others. And it doesn’t put any pressure on me.
So perhaps give Data Collection Techniques
only a cursory review not going into every detail? And then we use
Template:Maintainer to add @torjunkie as maintainer of it?
What do you think?
2 Likes
Yes. Any topic that isn’t integral to Whonix, or that Whonix doesn’t have unique expertise in, will eventually become unmaintained. The more the text, the greater the burden.
Essential topics should have:
- actionable user advice
- brief justification
- references to support
Also, yes. There can be real value in researching topics thoroughly and compiling information gained from various expert sources into a cohesive, ledgible wiki entry.
How to accomodate both? This is a good opportunity for me to resume my whining from last year. I love the content in the wiki. The presentation and organization, not so much.
- Information overload can be helped by segregating non-essential, bonus topics to “advanced, further reading” sections.
- Lack of maintenance can be resolved by clearly identifying obsolete entries. Easiest (no intervention) way of doing this is by dating entries like blog posts. Authorship can be assigned as well. (Perhaps, new “Community Research” section.) If entries get audited / updated, then a new date + (co)author can be assigned.
For #1, I have no idea how to accomplish. It would involve moving large sections of pages to other pages, creating new pages, deleting lots of pages, creating / deleting sections, moving pages between sections. It would be relatively easy if I could fork the whole thing and present a unified pull. I don’t see how it’s possible without creating a huge mess in current situation.
(currently researching some of your concerns re: jekyll / git / markup. https://whonix.org/wiki/Dev/jekyll)
2 Likes
OK.
- I can’t be bothered with all the sys-whonix stuff. Too much effort for marginal use case. So I’m gonna leave all that and just slot in somewhere entr0py’s idea of cloning Whonix templates first etc. as a fallback & noting all the default Qubes Global Settings etc as per the post further above for use of alternative gateways.
(Ironically the system seemed to self-rectify itself after all that, except sys-whonix only auto starts some of the time. Good enough).
Aside: re: Qubes R4 - I’ll be waiting for a bit. Tons of bugs outstanding, no Qubes VM Manager etc is a big downside. Maybe 6 months later after release, when it is actually stable.
-
Re: Tor info outdated. Noted. Will fix up that relevant Tor section in wiki.
-
Re: edits you don’t like. Yeh - can probably be trimmed down a bit for cookies, but I do like my other edits to other sections…
-
Re: Anon-connection-wizard needs 0.3.1 Tor - noted. Needs a line in that section to update to latest Tor versions.
-
Re: benefits of using later Tor versions (security etc, with some minor risk of breakage), should be noted somewhere (from other thread).
torjunkie:
- Re: benefits of using later Tor versions (security etc, with some minor risk of breakage), should be noted somewhere (from other thread).
Ta. Fixed up most of the above stuff.
1 Like
Agreed
This is how
/etc/qubes-rpc/policy/qubes.UpdatesProxy
should look in Qubes R4 with Qubes-Whonix installed.
whonix-ws $default allow,target=sys-whonix
whonix-ws $anyvm deny
whonix-gw $default allow,target=sys-whonix
whonix-gw $anyvm deny
## Note that policy parsing stops at the first match,
## so adding anything below "$anyvm $anyvm action" line will have no effect
## Please use a single # to start your custom comments
# Default rule for all TemplateVMs - direct the connection to sys-net
$type:TemplateVM $default allow,target=sys-net
$anyvm $anyvm deny
If you were to clone whonix-gw to whonix-gw-14, and if you were to clone whonix-ws to whonix-ws-14, and if you created sys-whonix-14 and you wanted these TemplateVMs to use that as its ProxyVM, then
/etc/qubes-rpc/policy/qubes.UpdatesProxy
should look like this.
whonix-ws $default allow,target=sys-whonix
whonix-ws $anyvm deny
whonix-gw $default allow,target=sys-whonix
whonix-gw $anyvm deny
whonix-ws-14 $default allow,target=sys-whonix-14
whonix-ws-14 $anyvm deny
whonix-gw-14 $default allow,target=sys-whonix-14
whonix-gw-14 $anyvm deny
## Note that policy parsing stops at the first match,
## so adding anything below "$anyvm $anyvm action" line will have no effect
## Please use a single # to start your custom comments
# Default rule for all TemplateVMs - direct the connection to sys-net
$type:TemplateVM $default allow,target=sys-net
$anyvm $anyvm deny
In any case, after upgrading to Qubes R4 and Qubes-Whonix 14, the network setting for any Whonix TemplateVM should be set to none. This is because Qubes R4 uses qrexec based updates proxy. Qubes-Whonix 13 supports that as well after a usual apt-get dist-upgrade.
If you would like to document this, you’re most welcome to!
1 Like
→ Fixed
Off-topic - Phabricator clean-up suggestions:
- T730 - Chinese spam (delete)
- T410 - Grsecurity related - “won’t fix”
- T685 - uBlock Origin install - “won’t fix” (reduces anonymity)
- T716 - “Closed - Resolved” (?) - anon-connection-wizard now integrated
- T91 - “Closed - Resolved” (?) - Whonix is fully 64 bit from Whonix 14
- T190 - “Closed - Resolved” (?) - whonix-setup-wizard is now polished (?)
- T616 - “Won’t fix” - Anonymouth has not had commits for over 4 years = dead project
That “apt-get Qubes instructions” bug (T545) should be relatively easy to fix (?)
1 Like
Thanks, all fixed!
I think how to use multiple Whonix templates and multiple separate clones of sys-whonix / anon-whonix should also be implemented elsewhere than on the upgrade to Whonix 14 page. Imagine a user who starts with Whonix 14. We shouldn’t redirect to the Whonix 13 → Whonix 14 upgrade page. But this can surely wait until Whonix 14 gets released.
I am wondering if the user that posted https://forums.whonix.org/t/how-to-tunnels-connecting-to-a-proxy-before-tor was jumping to trying Connecting to a Proxy before Tor too quickly.
Could you please check if either Connecting to a Proxy before Tor and/or Combining Tunnels with Tor have an appropriate explanation that Configure (Private) (Obfuscated) Tor Bridges might be the more appropriate solution?
This paper written in 2012 claims that both public and private bridges are trivial to enumerate and block by sophisticated censors, like the Chinese. Anecdotally, we’ve had users here claim that it’s a widely known fact in China that Tor bridges do not work.
Glad to see that Lantern page. Too bad they moved to a pay model. Definitely need to document some alternatives that are free or accept more anonymous payment types. Perhaps, Bitmask VPNs could circumvent extensive censorship.
[edit] Lantern has really grown since I looked at it. https://github.com/getlantern/lantern/blob/devel/README-dev.md Seems reasonable that they would need a funding source.
2 Likes
Would you also like to revise user facing messages (gui windows, info/error messages, log output)?
For example recently i created the following one but I am sure the wording is far from ideal.
OK, we can wait until Whonix 14 is ready.
I’ll have a look.
Yes, that’s a good idea. Any easy way to track down the main ones?
2 Likes
Awesome!
I will write something about this soon. I’ll point you at some “manually” for start.
This one is prominent since it can be opened from start menu. Not sure how many people are reading it though.
https://github.com/Whonix/anon-gw-anonymizer-config/blob/master/etc/tor/torrc.examples
Does the github editor work for you?
Also anon-gw-anonymizer-config/etc/tor/torrc.anondist at master · Whonix/anon-gw-anonymizer-config · GitHub - exception this one only: but we cannot merge it soon. We might merge it for Whonix 15 when we include anon-connection-wizard by default.
Do you think people would look into anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist at master · Whonix/anon-gw-anonymizer-config · GitHub?
Btw don’t bother updating Copyright (C) 2012 - 2014 (etc.). No need. If you think I should higher priority to update it, I could do an easy mass search and replace so little manual labor would be used for this.
The generic readme. developer-meta-files/README_generic.md at master · Kicksecure/developer-meta-files · GitHub - very prominent - because it gets used on any github repository. GitHub - Kicksecure/sdwdate-gui: Grapical User Interface (gui), Systray Icon for for sdwdate - https://www.kicksecure.com/wiki/sdwdate-gui, https://github.com/Whonix/Whonix, GitHub - Whonix/onion-grater etc. everywhere.
Btw please don’t edit the upper part of github readmes. To change that content, that goes to debian/control such as for example sdwdate-gui/debian/control at master · Kicksecure/sdwdate-gui · GitHub. From there, README.md is sometimes auto generated. 80 characters per line maximum. I am not sure how many people read package descriptions besides reviewers. Would be more important if any Whonix packages made it into packages.debian.org.
VirtualBox import message:
1 Like