Can you please undo parts of this change? Please do not change any licensing texts.
There are organizations such as FSF out there who work with lawyers, fight in courts, etc. Since Whonix is Libre Software and not in the lawyerization business, we use their texts verbatim with the only exception of small changes as per their recommended best practices (i.e. to fill out gaps for name, copyright and year). If we were to change these texts, we would go into unchartered legal waters. Really not worth the risk.
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.
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?
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:
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.
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.
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!
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.
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?
‘‘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.
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.
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?
