How about this below as a summary of oustanding issues across this thread - many are trivial, not Whonix’s problem, or already partially/fully sorted.
I’ve ignored much earlier stuff about Anon-Connection-Wizard not connecting on first run, since TNT_BOM_BOM, I and others were using old templates & that seems to have been rectified in the latest template:
1) Note that the apparmor profile for VirtualBox (when installing apparmor-profiles-whonix) warns:
Warning from /etc/apparmor.d/usr/lib/virtualbox.VirtualBox (/etc/apparmor.d/usr.lib.virtualbox.VirtualBox line 50): Unconfined exec qualifer (ux) allows some dangerous environment variables to be passed to the unconfined process; ‘man 5 apparmor.d’ for details.
Not that I use VirtualBox or care very much, but probably something for @troubadour to consider.
2) No “Connected to Tor” GUI message (from Qubes platform) when Tor connects, as is seen in Whonix 13. Trivial issue and for Qubes devs to fix I presume. Qubes report?
3) Graphical issues inside Dolphin as reported by TNT_BOM_BOM (xfce nautilus interruption?) & Move/Copy to other VMs is not there (presumably a Qubes issue). Workaround: install nautilus. @TNT_BOM_BOM to report on phabricator?
4) Remove KDE-Help inside GW and WS as it might request suspicious requests which could leak potential data (TNT_BOM_BOM suggestion). @TNT_BOM_BOM to report on phabricator?
5) To be confirmed: No default shortcuts from Qubes-Whonix toolbar for sys-whonix & anon-whonix (TBC because I may have stuffed up a step - already reported to Qubes Issues). TBC.
6) Tor User Config change “Sandbox 1” (seccomp) to confine Tor process leads to a Tor crash. ConnectionPadding 1 by itself works okay in the config file. Already reported to Tor Project.
7) Template downloads errors - qubes-rpc-multiplexer & verification error on template. @BubonicChronicWhonix to report to Qubes?
8) Onion sources not used by default when upgrading Whonix 13 to Whonix 14 - requires sudo whonix repository --enable --codename stretch. Fixed.
9) The Tor Browser tabs GUI is a little messy i.e. grey and white color instead of just uniform grey. Trivial issue and no doubt related to Debian, Qubes or Tor Project code. Known issue in KDE - probably beyond Whonix scope.
10) Multiple old Whonix builds in unstable Qubes repos. Fixed already.
WHAT IS WORKING
All main things seem to work now with an updated template - who would have thought ha ha
Anon Connection Wizard
New Whonix landing page
Whonixcheck on both AppVMs
Alpha and standard Tor versions
v2 / v3 onions
Changing Whonix repositories
Updates / dist-upgrade
FURTHER TESTING REQUIRED
Bridges & meek plug-ins via Anon Connection Wizard
Richochet, OnionCircuits, OnionShare (?) and various other apps
Sandboxed Tor Browser (the Tor Project one)
Other random things
Should we be seeing many, many socks listeners on ports in the 9000+ range and warnings about “You configured a non-loopback address XX.XXX.X.X:XXXX” in the logs?
Can anybody confirm if you got the defaut shortcuts from the Qubes toolbar in sys-whonix and anon-whonix i.e. did you immediately see Konsole, Anon Connection Wizard etc or did you have to manually add the shortcuts?
Any other problems from testers to add to the above list?
The torbrowser GUI issue (mis-coloring of tabs) disappears if you qvm-copy torbrowser from a whonix-ws-14-based VM to a regular qubes debian stretch VM and then run it from there. So it’s a whonix (or maybe KDE?) specific issue?
Messing with systemsettings5 > Application Styles doesn’t seem to fix it.
Even after following steps 5 to 8 as currently written, this command doesn’t create a Whonix 14 sys-whonix.
Prior to running this I had a working whonix-gw with stretch sources.
AFTER the command, I see this error:
whonix-gw: VM directory does not exist: /var/lib/qubes/vm-templates/whonix-gw
Is this just me?
Can anyone who’s followed these instructions check what sys-whonix is actually running.
(If it’s relevant I kept my old templates as -13 versions and retained a sys-whonix-13.)
I actually saw this problem in R3.2 the second time around running salt. I ignored the problem and configured AppVMs manually, since I though I did something wrong.
Salt is great in theory, but sucks for normal users (like me).
I reckon it is better to point out in the steps that if a user encounters problems with salt, they simply create the sys-whonix ProxyVM and anon-whonix AppVMs manually from Qubes VM Manager, and imitate the network settings as per “old” sys-whonix and anon-whonix i.e. sys-whonix points to sys-firewall and anon-whonix points to sys-whonix.
I presume this is good enough to confirm it’s correctly using the system Tor process?
Note also that the sandboxed Tor Browser does not see the Adawaita Gtk theme - don’t know if we give a shit or not to note optional install of it for the wiki instructions. Left it to the user to decide in the wiki instructions.
@0brand - that’s fine, but you don’t explain how users can tell the difference.
I would not include this but mandate the manual method since we know that salt will fail for some users attempting upgrade. I’ll raise issue against Qubes re salt use.
if you’re considering not using salt, then why not just update the templateVM setting of the existing sys-whonix and anon-whonix? And they are presumably originally set up the “right” way by Salt.
Otherwise you need additional steps to create new VMs, then duplicate whatever Salt does (e.g. set anon-vm tag to prevent clock correlation, …), and you have to manually set RAM / firewall / NetVM / templateVM settings, yeesh.
Again, if you reuse sys-whonix and anon-whonix, you can upgrade in 4 steps :
No cloning, no renaming, just change two templateVM settings. It’s very Qube-ic.
 I also had to fix permissions, in sys-whonix: chown -R debian-tor:debian-tor /var/lib/tor
This way, the steps to install template VMs are tested. This issue would not have been know if Whonix 13 templates were updated to Whonix 14. If a user has to reinstall a Whonix VM template due to VM corruption the step to do so will be sound because they were tested.
Also at the end of the instructions
It should be noted that users also have the option of doing an in-place upgrade of Whonix 13 to Whonix 14, rather than using the release candidate TemplateVMs. If this is preferable, follow the Testers-only documentation at the link below.
Once again, this is testing to ensure everything works as it should. With cloning sys-whonix, how is is known if Anon Connection Wizard works? etc. etc. etc…
Yes I know. I was trying to get the point across that doing things like that, although it may work, does nothing to work the bugs out of installing/configuring etc. Whoinx 14 VMs. I mentioned this to you before.
Just wanted to add:
Its a good idea and it would make the instructions much easy/simpler. However, its important that all the bugs get worked out prior to Whonix 14 being blessed stable. Cutting corners while testing (even if they are Qubish) should be avoided. This way problems will be found sooner rather than later.
P.S. If you would like to help edit the instructions to create Whoinx 14 VMs manually and salt as optional…
I also see @0brand’s point, re doing the full blown test to identify any issues across the whole spectrum e.g. as we discovered with running salt twice causing errors i.e. unman and I got that error.
Anyhow, no1’s earlier post pointed out a very serious issue with manual tinkering and not using salt (in Qubes R4 only I think?).
I see in Dev/Qubes it outlines what salt is doing. Most of it expected, except that anon-vm tag stuff. Didn’t even realize that tag existed to prevent clock correlation/time syncing risk!
I understand the tags only exist in Qubes R4 though (?), as 3.2 dom0 doesn’t recognize the qvm-tags command which Rutkowska refers to in her next gen qubes core stack article.
Anyhow, this could be a massive issue and a huge, fat warning might need to be in wiki docs that the (very likely) user expectation of using new whonix-templates to create new sys-whonix and anon-whonix (without resorting to salt) potentially puts the user at risk of de-anonymization, since no anon-vm tag is applied e.g. see here for example: