There is only one mistake.
Old
- [[ExoneraTor|ExoneraTor:]] a [https://exonerator.torproject.org/ Website] that Tells You Whether a Given IP Address is a Tor Relay
New
- [[ExoneraTor|ExoneraTor:]] a [https://exonerator.torproject.org/ Website Tool] to Check for Tor Relay IP Addresses
This seems like a bug. Meaning changed and got wrong.
Quote https://exonerator.torproject.org/
Enter an IP address and date to find out whether that address was used as a Tor relay:
All of these really but especially the first one which is what makes this special.
I suggested VoIP to ricochet a while back with radio silence on that ticket. unMessage are interested in implementing this at some point. No other anonymous solutions for VoIP planned AFAIK.
If both users are communicating over anonymously created accounts and the VoIP streams are encrypted this shouldn’t be a risk.
Is there some overlap between these two chapters?
You’re right. I think the time sync related stuff should be moved out from the sec guide.
Security Guide - Whonix causes some confusion. Missing torproject apt signing key. ( https://forums.whonix.org/t/gpg-error-when-onionizing-tor-project-updates )
Security Guide - Whonix why onionize torproject repository in the workstation? Fixed to gateway.
Enabling torproject apt repository is now documented here, you might like to revision it: Security Guide - Whonix
You changed the link text to Increasing the Virtual Harddisk in documentation index. Should we therefore also move the page from Grow_Virtual_Harddisk to Increasing_Virtual_Harddisk?
“Expanding Virtual Harddisk” sounds better?
Greetings
Sorry for the absence. Been busy with a few things, but I hope to recommit to part-time editing again within the next few weeks!
Apologies for those errors. Normally I test beforehand. Good to see users haven’t reported anything else being wrong (yet).
1) Re: Tor Project key. As I’m away from my main machine, check the following is correct before I add it as a first step at the top of that entry →
First, import and verify the Tor Project signing key (0x4E2C6E8793298290). In the Whonix-Gateway or the whonix-gw TemplateVM (Qubes), open a terminal and run:
gpg --keyserver pool.sks-keyservers.net --recv-keys 0x4E2C6E8793298290
Verify the fingerprint is correct:
gpg --fingerprint 0x4E2C6E8793298290
The output should show:
pub 4096R/93298290 2014-12-15
Key fingerprint = EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290
uid Tor Browser Developers (signing key)
sub 4096R/F65C2036 2014-12-15
sub 4096R/D40814E0 2014-12-15
sub 4096R/C3C07136 2016-08-24
2) Yes, I’ll revise that apt repository entry when I have time in the coming weeks. I don’t like that information being in the checklist area, since that is supposed to be short and sweet (with links).
3) I don’t mind either terminology re: “Expanding the Virtual Harddisk” or “Increasing the Virtual Harddisk”. Whatever works for you.
BTW exciting to see the developer work ongoing re: anon connection wizard and other things. Good times. 
Unless you have specific requests for other documentation needing urgent editing, I’ll recommit to finishing the uncategorized Whonix wiki templates and then move onto the Advanced Security Guide from there.
As a habit please include the full key fingeprint between “” for the recv-keys command. Example:
gpg --keyserver pool.sks-keyservers.net --recv-keys “EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290”
OK - that’s done and awaiting sign off.
I changed Patrick’s (Whonix Updates) text to a single bullet point in the checklist and moved (and edited) all his text to an additional entry in the security guide called -> “Tor Versioning”.
I also added the long key ID under the section re: onionizing Tor Project updates and checked it works correctly.
Cheers
Added Yubikey in the security checklist (for Qubes-Whonix) under the heading “Multi-Factor User Authentication” and have gone through another 15 wiki templates or so.
I think there is only around 100 templates left to go. Yah! 
Great to see you are back on editing spree. 
A few comments.
It’s never Tor TransPorts. It’s really Tor's TransPort. We could put SocksPort and TransPort into code tags like {{Code2|TransPort}} and {{Code2|SocksPort}}s perhaps?
SocksPort and TransPort refer to configuration keywords in Tor’s config (in Whonix (tor-service-defaults-torrc), which are are documented in the Tor manual. Whonix uses only one Tor TransPort keyword, as it makes no sense to have multiple TransPorts in Whonix.
Template:Qubes AppArmor: Difference between revisions - Whonix
was:
You will want to complete the following directions in both the Whonix-Gateway (commonly called whonix-gw) and the Whonix-Workstation (commonly called whonix-ws). You only need to apply these settings to the TemplateVMs before creating any TemplateBasedVMs based on Whonix templates.
new:
The following steps should be completed in dom0 for both the Whonix-Gateway (whonix-gw) and the Whonix-Workstation (whonix-ws) TemplateVMs. Applying these settings to the TemplateVMs will ensure that AppVMs based on Whonix templates will inherit the AppArmor settings.
Comment: when there are already existing AppVMs based on whonix-gw / whonix-ws and you enable AppArmor kernel settings for whonix-gw / whonix-ws, these existing AppVMs won’t be having AppArmor kernel settings enabled. Only newly created AppVMs will inherit it. I think this may not be clearly communicated before, but now it may be totally lost. Could you edit to add this please?
was:
‘‘a) Attach Whonix TemplateVMs to a Whonix-Gateway ProxyVM (commonly called sys-whonix)’’
new:
‘‘a) Attach Whonix TemplateVMs to a Whonix-Gateway ProxyVM (sys-whonix)’’
Comment: I am not sure it’s a good idea to remove the commonly called part, since it’s not as hardcoded as one might think. One could have multiple AppVMs and the commonly called part is there to communicate that it’s not a hardcoded VM name.
Optional: Onionize Tor Project Updates
uid Tor Browser Developers (signing key) torbrowser@torproject.org
That must be wrong. The Tor Project deb apt signing key is not the TBB signing key.
Theres should be no need to get that key anyhow. The way to onionize Tor Project apt repository would be to install the anon-shared-build-apt-sources-tpo package as under Tor Versioning (that adds the key) and then switch /etc/apt/sources.list.d/torproject.list onion sources.
Fixed.
Fixed.
Fixed in two templates.
…
Whoops! Didn’t realize that. Fixed.
After the edit of Template:Software compartmentalization vs. physical separation - Whonix, now where the template is used ( Why use Qubes over other Virtualizers? ) looks a bit off?
Re Qubes AppArmor: (Not an issue that you introduced… Just noticed that now due to discussing this here.) But when installing Qubes-Whonix by selecting it in Qubes installer and then applying either Template:Qubes AppArmor - Whonix or enabling apparmor from Redirecting…, users would miss enabling AppArmor in sys-whonix and anon-whonix? Could you fix that please?
After much pain and suffering, I have fixed/merged both of these.
Basically, all the stuff was merged into the ‘Why use Qubes over other Virtualizers’ entry (plus a shit load more bullet points), and I just cut the Rutkowska template back to one paragraph re: summary outcome of her research.
So, it all looks nice and thorough now.
Do you mean just note a step that the user should recreate sys-whonix and anon-whonix AppVMs after applying the new kernelopts with AppArmor initialized?
If so, easy enough.
BTW - that is not my recollection when I did it on my system i.e. I thought that it worked okay with pre-existing AppVMs, since the tests resulting in ouput ‘0’ (for existance of AppArmor framework) came up trumps from memory. So, I do actually wonder we have this right…
There is no reason to recreate. Just set the kernel options.
Just now tested. Changing kernel options for whonix-ws does not modify kernel options of anon-whonix. (Checked with qvm-prefs -l anon-whonix kernelopts and in VM with sudo aa-status.)
Template:Tor_Browser_Remove_Proxy_Setting
Template:Qubes_AppArmor
I must admit I’m very confused now.
Do you mind cutting and pasting from that entry exactly what is wrong and tell me what needs to be deleted/added re: this process.
As I understood it, we:
Did all that stuff in dom0 (as currently exists in the entry) to show AppArmor is part of new kernel parameters for whonix-ws and whonix-gw (TemplateVMs)
Magically, newly created TemplatedBasedVMs (AppVMs) based on whonix-ws and whonix-gw (ie anon-whonix and sys-whonix) would inherit the same kernelopts, since according to Qubes:
“Newly created TemplateBasedVMs inherit the kernelopts setting of their TemplateVM.”
Thus my reasoning was a) since we already specified whonix-ws (TemplateVM) and whonix-gw (TemplateVM) in the dom0 steps b) sudo aa-status should output “0” for both (freshly created) instances of appVMs.
But you’re saying that doesn’t work?
So, if AppVMs don’t inherit this value when created after dom0 steps, and you’re saying we don’t recreate AppVMs based on modified TemplateVMs, we should then set kernelopts directly to the AppVMs like so (?):
qvm-prefs -s anon-whonix kernelopts “nopat apparmor=1 security=apparmor”
&
qvm-prefs -s sys-whonix kernelopts “nopat apparmor=1 security=apparmor”
Is that right? If not, then I’m completely stumped and I have no idea how to proceed to fix this entry 