Long Wiki Edits Thread


Created new page Qubes/Clone VMs


Added to Multiple Whonix-Workstations


1 Like

70defaultrelease works with no problems.

Using -t buster causes the same dependency problem that causes the current wiki instructions to fail.

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libkf5coreaddons5 : Breaks: libkf5auth5 (< 5.47) but 5.28.0-2 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

It looks like no -t option for now, but there is another option.

sudo apt-get install electrum/buster

Selected version '3.1.3-1' (Debian:testing [all]) for 'electrum'

I haven’t come across any issues while using these instructions.




OK, so we don’t need 0brand’s post about EOL then. You should just copy that Qubes text verbatim and insert into Whonix News forum.

whonixcheck page -> All fixed

Now going back to link fixes.

@mig5 - I understand you are former OnionShare dev? Would you mind looking over these instructions for accuracy or possible hardening please?


Of interest: AppArmor profile in Whonix works? How? What’s the more secure configuration in the panel options? etc.


Hi @torjunkie

Not former but current core dev alongside Micah.

The docs look pretty good. A couple of suggestions/notes however:

  1. Consider not mentioning the current version 1.3, or any other version. You’re only making work for yourself trying to keep the docs up to date (i.e every time OnionShare gets a new release). May as well not mention version, and make your life easier. Case in point: v.1.3.1 is the latest version.

  2. Likewise for step 6 where you list the dependencies to install. We already have that in the BUILD.md of the onionshare repo. Maybe there’s a nice way to say ‘please run the apt-get commands seen in the ‘Debian-like distros’ section of the BUILD.md in the OnionShare repo’, so that if we change dependencies, you don’t have to update obsolete documentation.

  3. Nothing you can really do about this right now, but there’s an unfortunate bug in the OnionShare ‘develop’ branch (which is the default branch) , which causes the app to crash when opening the Settings dialog. Therefore, the step where you edit settings to set the Tor connection method to ‘via control socket’, crashes. This is obviously only a temporary issue until Micah merges in a fix that’s been sitting in the queue for ages, but I can’t force him to, and we have a workflow whereby we review each other’s patches.

As a temporary workaround, you could consider either telling the user to checkout the ‘master’ branch, or, as I did in my testing just now, the latest release tag (v1.3.1 - yes I realise this then re-introduces the issue in my point 1 above, about hardcoding release numbers into your docs).

  1. The note ‘Check “Create stealth onion services” to make OnionShare operations more secure.’ is a bit too brief: it should be noted that enabling Stealth also requires action from the user fetching the files, in that they need to edit their torrc (Stealth just means ‘onion service Client Auth’.) We already have this documented, so again, you could maybe append "Note, however, that using Stealth mode makes it harder for the end user to connect to the share, because it requires them to edit their torrc. Please see the official documentation at https://github.com/micahflee/onionshare/wiki/Stealth-Onion-Services for more information’

Suffice to say the instructions otherwise worked for me.

The AppArmor profiles probably won’t work against the recent releases or against the develop/master branches of the git repo. They are super old. The contributor who has unofficially maintained/provided our AppArmor profiles has even opened a ticket saying they are out of date and need to be replaced: https://github.com/micahflee/onionshare/issues/686

We are hoping to get new AppArmor profiles from them ‘soon’. Not sure how to portray this in your docs, but for now I would not try AppArmor with OnionShare unless you are good at AppArmor profiles, and maybe if so, you can help contribute fixes via the above ticket.

As above - the only real element that currently adds extra security is Stealth mode (ClientAuth).

An additional method to reduce the risk of onion service discovery attacks is to use the Shutdown Timer setting. This allows you to self-destruct the share if no-one came and downloaded your share within an acceptable time window.

Unsetting ‘Stop sharing after first download’ is also obviously a risk as it will keep the share open after someone downloads the file (but obviously useful for sharing to multiple users or long term shares). Likewise Persistent mode is a risk as it re-uses the Onion address instead of a random one each time.

Again, I wouldn’t bother pointing any of this out, as it’s all documented in the OnionShare wiki already. Point any ‘using OnionShare’ advice to the official docs to save yourself effort. The Whonix wiki page should only show Whonix-specific steps required to install or configure OnionShare.

Hope this helps



Took @0brand’s version since https://www.qubes-os.org/news/2018/08/24/whonix-13-approaching-eol/ is too Qubes specific.

Whonix 13 approaching EOL (End of Life) - 2018 September 30 - all users must upgrade!


Microcode needs to be installed on the host.

  • Not the default in Linux, Debian? dpkg -l | grep microcode
  • Default in Qubes? dom0: dnf list | grep microcode
1 Like

Thanks mig5. All very sane advice.

@0brand - I nitpicked your EOL announcement. Hope that’s okay (good job BTW :metal:)


Small nitpick: ARM is less affected and the processor in the rpi is not affected at all. In case your processor is affected you should always install patches on the host/bare metal.

1 Like

All fixed.

I didn’t add that to that Firmware section. You want those steps there somewhere?


And not widely known in community / explained in wiki (much). Hence why Xen only has low 100s in identified bugs, where Linux / Microsoft is through the roof. Will note & add that link to microkernel research i.e. you’re screwed on normal Linux platform by comparison.

Yet another reason to run Qubes, and have a small target at the core of your system.



All fixed.

I didn’t add that to that Firmware section. You want those steps there somewhere?

In firmware section and linked to it from related places.

1 Like

Kernel versions and security reminds me… https://www.whonix.org/wiki/System_Hardening_Checklist#Newer_Kernels

sudo apt-get install -t stretch-backports linux-image-amd64 linux-headers-amd64

Do we have this documented somewhere?

No not documented for the kernel.

1 Like

Updated Electrum documenation


Unfortunately when taking screenshots for electrum the screen would not shrink to a smaller size. Only during configuration though. Had to use larger size screenshots than normally would have.

I’ll work on this then I’d like to complete the Qubes/DispVM TODO’s


torjunkie, I’m working on those flash screenshots to. Actually already have them but the information would not fit on one screen. (large gap between information) Trying to neatly cut and paste both screenshots together.

Patrick, I can start experimenting with:


electrum! Yes! :slight_smile: Could you please notify the forum discussion threads?

update vs upgrade - definition - meaning suggesting and finding consensus among what update means, what upgrade means. Like word reference.


Fixed WS and GW size (in template) based on your forum thread i.e. around 50% reduction:

  • 850 MB (GW)
  • 1.1 GB (WS)

Let me know right away if that isn’t right. Also updated Whonix 14 release forum post, which had incorrect figures.

The Whonix-Gateway is reduced from 1.7 GB to 850 MB, while the Whonix-Workstation is reduced from 2 GB to 1.1 GB.

Fixed. Although I didn’t add HulaHoop’s step below (because I just saw it). Can add if you want:

Compare your microcode version number before and after updating to see if its applied:

sudo dmesg | grep “microcode updated early to”

If it succeeded it should say something like:

microcode: microcode updated early to revision X


In the process of fixing… we should recommend for host AND Whonix VMs right? So add to “Host Security” page of Basic Security Guide - seems like a nice fit there and Whonix-WS and Whonix-GW security pages for VM kernel I suppose.

Good job 0brand. You are getting some very solid contributions under your belt, and I for one welcome it! More please :slight_smile:




Yes please.


@Patrick My bad. I thought that Debian had added a v3 onion repo but it was a Whonix url I was changing it to. Good catch.

Do you think we should recommend the onion address as a safer default, considering tht we will be transitioning to a fully onion repo list soon.

I don’t expect too soon. Waiting Debian onion v3 (to proof Tor onions can handle the load) and maybe for onionbalance v3:
Onionizing Qubes-Whonix Repositories

https://www.whonix.org/wiki/Onionizing_Repositories could say “for better security, disable clearnet and leave onions only”. Added that but undocumented.

https://www.whonix.org/wiki/Onionizing_Repositories has some imperfections.

  • sudo nano

    • nano vs graphical editor
    • do we have a wiki template for that?
    • we have https://www.whonix.org/wiki/Template:Open_with_root_rights but that is for Whonix only, not guaranteed to work outside of Whonix (actually fails in Qubes Debian templates since these don’t have kwrite installed by default)
  • /etc/apt/sources.list.d/debian.list

    • Whonix: correct
    • plain Debian hosts and Qubes Debian template: incorrect, it’s /etc/apt/sources.list
  • Maybe instructions shouldn’t be by Debian packages, Whonix packages, Tor packages, Fedora packages. Perhaps better instructions for:

    • Qubes dom0
    • Qubes-Whonix TemplateVMs
    • Qubes Debian TemplateVM
    • Qubes Fedora TemplateVM
    • Non-Qubes-Whonix
    • plain Debian hosts
  • Then each chapter could contain instructions to onionize it as much as possible.

    • Whonix: from onions/clearnet to exclusive onions
    • others: from clearnet to exclusive onions
1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]