im not replacing the screenshot , i want someone to replace it.
We need to make a page about Mac Hosts similar to Windows Hosts.
Mac Hosts page can be filled from info here.
Not sure we gain much by importing other pages. We don’t really have anyone to maintain https://www.whonix.org/wiki/Windows_Hosts either. It exists now and has some info but no one really working on it actively (engage with community, capability to debate/clarify).
Coming to mind perhaps wanting to improve https://www.gnu.org/proprietary/malware-apple.html would be @torjunkie. But I leave it to the volunteer to decide if that is a good/fun use of time.
I agree pages could use an update (Qubes/Uninstall, new page Reinstall TemplateVM R4.0) I have a few thing to finish then I’ll start on this.
P.S Install whonix-gw-13 from backup to reproduce behavior from the following issue didn’t produce anything yet. Will try again.
Changes rejected. Reasons:
Factually incorrect. Implies properly implemented IPSec, TLS and SSH is vulnerable to MITM attack if router is infected and that is not true. These protocols are resilient in face of untrusted middle nodes across the internet.
Not directly relevant to Whonix. Whonix security does not depend on whether your router is safe or not - therefore does not deserve such depth. In many cases you don’t have a choice in the software your network uses because it is not your network if you are on the go.
Even with a safe router, you are still hosed if family members run untrusted devices with proprietary spyware like Windows or out-of-the-box Android ROMs.
Implies you can be safe from targeted attacks - practically impossible in face of the adversaries mentioned and therefore false.
A laundry list of NSA/GCHQ tooling when the phrase “software or hardware implants” will do.
I think this page should say off the shelf routers should not be considered trusted and leave it at that. This means deprecating these sections.
The whole router/Wifi hardening guide is kinda pointless considering this. FOSS firmware recommendations are welcome. Open Hardware DIY guides, even better.
Saving time, as the gnu page made with strict laws about what to include and from where.
Doing our own research will improve more for sure.
apt-get-update-plus should be documented in “Operating System Software Updates”. Yes?
apt-get-update-plusshould be documented in “Operating System Software Updates”. Yes?
Once there is a new build of Whonix, yes. (Otherwise we have a messy
state where not everyone can be reasonably expected to have it.)
Added “Spawning DispVMs from other AppVMs” to Qubes/DispVM. This TODO is not complete. Creating Named Whonix DispVM Based on Whonix-Workstation complicates this a bit.
For example, if the
name-dispvm is not running it is possible to use (Qubes secure copy)
qvm-copy some-file to the
named-dispvm even if it is not running or
defaut_dispvm for that AppVM. The
named-dispvm will start just like a normal VM to receive the file. This is not normal DispVM behavior?
Also of concern if the
name-dispvms have to be shut down like a normal AppVM. Meaning the following does not apply.
A DispVM automatically shuts down when the first user-launched process is terminated
I’ll be working on documenting
named-dispvm next. And finishing the TODOs.
Opps almost forgot.
8 posts were split to a new topic: SecureDrop Journalist Workstation based on Qubes-Whonix
Could you give this unpublished draft a revision please? @torjunkie
Mostly fixed (plus associated qubes pages).
Tox - how to fix instructions.
So Tox can’t be downloaded simply as a package for Debian.
The GitHub instructions want you to build it from source for Debian (yeh, no thanks - too hard, too many steps).
That Opensuse guy stopped packaging it for Debian stretch (so that won’t work anymore).
But, I see there is a AppImage for qtox on the official download page: https://tox.chat/download.html#gnulinux
Since this is a wonderful new thing e.g. see here:
I presume we can just fix the instructions to say:
Download this thing into Whonix-Workstation (anon-whonix)
Mark it as executable chmod a+x Some.Appimage
Install fuse if necessary as a dependency
sudo apt-get install fuse
- Double-click on the file to run it.
While this will work, it’s not exactly safe i.e. downloading random thing from Internet and run compromised (?) AppImage without verification (how is verification done here, is it even possible?)
I think we just mark it as less-than-ideal security, but at least working instructions. Right now we have “current instructions don’t work”, which is pointless.
We can point advanced users to the GitHub build instructions to do it themselves.
Also, Retroshare is too large to be on the Chat page. Needs its own page, so I’ll go and split that off. Chat page should be general description (like the email one), with detailed stuff left to stand-alone pages.
apparmor page needs an update as there is no more apparmor-profiles-whonix
Please don’t alphabetically sort items on the Chat and perhaps some other pages. The rationale is: sort by highest order of recommendation.
The provider of the appimage (ideally same as developer of tox) could provide gpg signatures. People can gpg sign any kind of files.
Package doesn’t exist or just changed name? If it doesn’t exist, we just have to delete one section, easy.
OK. But we need to explicitly state that i.e. ranked in order.
Yes, but I was wondering about possibility with no advertised sig & key associated with that. Why don’t they put this on front page in an obvious place? Boggles the mind how uber-geeks lack common sense. No wonder their users are in the 100s or 1000s, because nobody can install it securely, 5 years after they started developing…
Anyway, this should work below and be easiest for Non-Qubes-Whonix? Reasonable?
Will not work in Qubes-Whonix due to blocks on downloading random stuff into TemplateVM at steps 2 & 3 ie “can’t load uri” etc. So another solution is required or one could just bypass it by downloading in non-TemplateVM and just shift it between qubes.
== Installation ==
| type = notice
| image = [[File:Ambox_notice.png|40px|alt=Info]]
| text = Non-Qubes-Whonix only.
As qTox is not currently available as a stand-alone Debian package, users have three choices in late-2018:
- Build the package from source (difficult).
- Rely on an unsigned, self-contained AppImage downloaded from the Tox homepage (insecure).
- Install Flatpak from stretch-backports and then install Tox from the Flathub repository (easiest).
== Flatpak Method ==
.flatpakrepofiles generally include the base64-encoded version of the GPG key that was used to sign the repository.
Steps for the Flatpak method are outlined below.
‘’‘1.’’’ Install Flatpak.
Note: It is recommended to create a separate Whonix-Workstation before installing addtional software. Also qTox is alpha software which has not been formally audited, therefore it is less trusted.
Flatpak must be installed in Whonix-Workstation from Debian backports.
‘’‘2.’’’ Add the Flathub repository.
Flathub is a common place to source Flatpak applications. To enable it, run.
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
‘’‘3.’’’ Restart and install qTox.
A restart of Whonix-Workstation is necessary for flatpak to finish setting up.
To install qTox from flathub, open a terminal (Konsole) and run. https://flathub.org/apps/details/io.github.qtox.qTox
flatpak install flathub io.github.qtox.qTox
‘’‘4.’’’ Start qTox.
To launch qTox, run.
flatpak run io.github.qtox.qTox
changed from apparmor-profiles-whonix to apparmor-profiles-hardened-debian.
also i dunno if these profiles are valid for whonix-gw , as i can see all of the profiles targeting the WS but i leave that answer to @Patrick