Long Wiki Edits Thread

Indeed.

I am wondering if it’s better to wait until the kicksecure.com domain is ready. It’s done but hidden behind http simple authentication. Otherwise that would confuse search engines.

Rewriting the whole wiki though to remove anonymity aspects and make it security only is a big effort and progress is slow unfortunately.

What I’d like to avoid is anyone confusing Whonix vs Kicksecure.

Could you review Account and Mobile Security: Difference between revisions - Whonix please? @HulaHoop

1 Like

Good. Approved.

1 Like

1. OK, so:

So that leads us to Chapter 4 Sandboxing:

Linux Hardening Guide | Madaidan's Insecurities

I think we should create a standalone page (full licensing) for this one, but with a focus on systemd sandboxing. The other stuff can be for the introduction i.e. sandbox escapes etc.

We can also reference your addition to the security hardening checklist: ~krathalan/systemd-sandboxing - sourcehut git

Does this apply to both Whonix VMs and host, or just the host? (I presume it applies to Whonix also.)

If you agree, I’ll go ahead and create and populate that page.

2. GNUnet

@hulahoop

This section is very confusing:

Users have to do all this then attempt to install GNUnet? Or the other way around? It needs a basic explanation upfront why this (chroot) is required (or not if optional and they want to take the risk).

What about if I want to run the latest version from the GNUnet website, see:

GNUnet

Once I know, we can add instructions for always downloading and verifying the latest versions from here (14.1 at the time of writing):

Index of /gnu/gnunet

With this key:

GNUnet

So we should show instructions for these as the example:

gnunet-0.14.1.tar.gz
gnunet-0.14.1.tar.gz.sig

I also presume all of this is happening in Whonix-WS, and just the installation steps in Whonix-WS-15 template VM in Qubes-Whonix (obviously we’d recommend a separate template and AppVM for this purpose).

1 Like

I suggest to slow down with importing contents from madaidan until licensing is sorted out.

A post was merged into an existing topic: Locking down your SSH Server and Client

You’re right. It was a brief brainstorm about an idea to make a more censorship robust notification system and it doesn’t belong on here, but on the permanent take-down threat ticket. As for the mmdebstrap steps below it, i have no idea how those got here (weren’t added by me I think) or how they help in installing the thing itself.

I was never able to get it to work and still don’t know why.

1 Like

A post was split to a new topic: Tor Browser getClientRects fingerprinting

2 posts were merged into an existing topic: very hard to notice Phishing Scam - Firefox / Tor Browser URL not showing real Domain Name - Homograph attack (Punycode)

Could you review Full Disk Encryption: Difference between revisions - Whonix please? @HulaHoop

1 Like

Should I move very hard to notice Phishing Scam - Firefox / Tor Browser URL not showing real Domain Name - Homograph attack (Punycode) from news to development forums? Same URL would remain functional.

Not in news forums disadvantage: someone really digging through news wouldn’t find it. Otherwise burried since posts in news forums aren’t bumped for new replies. But perhaps is OK if this moves to documentation instead.

If in development forums advantage: the thread gets bumped, more visible.

Good idea.

Scratch that. It’s visible under Whonix Forum which is a great button to stay in the loop anyhow.

Dev/Issues Tracker wiki entry could do with an update to show your preference in I assume this order:

  1. GitLab
  2. GitHub
  3. Phabricator

Also, I see The Tor Project GitLab issues trackers all have an onion address, but the Whonix one doesn’t. It would be great to set that up if possible from your end for interested devs & advanced users who want to check out issues.

1 Like

Made a slight update.

The preference is:

  • Please do not use GitLab / GitHub for issues. Easily overlooked. Hard to follow for the public. Pull requests are OK but please notify this forums.
  • Phabricator is legacy only. Ideally all tickets could be web archived, solved and/or migrated to this forums so it can be shut down.

Onions are available…

Current issue tracker:
http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/

Legacy issue tracker:
http://phabricator.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/

Primarily documented here:
https://www.whonix.org/wiki/Reporting_Bugs#Issue_Tracker

Dev/Issue Tracker - Whonix are just some notes.

Could you review Full Disk Encryption: Difference between revisions - Whonix please? @HulaHoop

1 Like

I’m impressed by the contribution quality.

1 Like

Yes. Impressive additions such as this Malware and Firmware Trojans: Difference between revisions - Whonix (confirmed)

Wiki getting a lot of praise due to contributions and professional English technical language. :slight_smile:


Could you review Out-of-band Management Technology: Difference between revisions - Whonix please? @HulaHoop

1 Like

I see online that 2FA examples for Linux are primarily for SSH logins.

You have an example of KeePassXC on that wiki page, anything else that should be highlighted there as an example?

PS that STMAN guy on Twitter says he solved his advanced adversary problems by using a disp sys-whonix. You might want to point out that he is destroying his anonymity in the process i.e. lack of persistent Tor entry guards. Maybe quote this:
http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Qubes/Disposable_VM#Warnings

Using DispVMs for both the Whonix ™ Gateway and Workstation in Qubes R4 does not increase security without any corresponding privacy downside, for the following reasons: [17] [18] [19]

DispVMs are not amnesic. In practice this means traces of their activity can be left on storage or in memory, making them vulnerable to forensic operations. [20]

Using a DispVM for the Whonix-Gateway ™ results in non-persistent entry guards to the Tor network; behavior unlike the default configurations for Whonix ™, Tor, and the Tor Browser Bundle. Mathematically speaking, end-to-end correlation attacks are more likely to succeed when a user chooses many random entry and exit points in the Tor network, rather than semi-permanent entry guards which are only rotated every few months. [21] [22]

1 Like