[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Long Wiki Edits Thread

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

Cheers

3 Likes

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!

2 Likes

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:)

3 Likes

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?

Fixed.

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.

2 Likes

torjunkie:

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

https://whonix.org/w/index.php?title=Electrum&diff=36329&oldid=36328

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

Edit:

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:

2 Likes

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.

@onion_knight

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

https://wiki.debian.org/Microcode#Checking_the_microcode_version_of_your_CPU

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:

3 Likes

Done!

2 Likes

Yes please.

2 Likes

@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

As discussed with Marek and adw.

As for future Whonix support timelines… To have something doable…

  • once a new stable Qubes version is released, shortly after, there might be a 1 month notice to upgrade to that newer version of Qubes if users wish to keep using Qubes-Whonix

  • once a new stable Qubes-Whonix version is released, shortly after, there might be a 1 month notice to upgrade Qubes-Whonix if users wish to keep using Qubes-Whonix

  • once a new stable Non-Qubes-Whonix, shortly after, there will be a 1 month notice to upgrade Whonix if users wish to keep using Whonix

  • once a new stable Debian is released, shortly after, there might be a 1 month notice to upgrade Debian, if users wish to keep using Whonix

<ref>This is to relieve Whonix developers from having to diagnose and support old-stable versions of Qubes/Debian/Whonix which results in a lot duplicate maintenance effort.</ref>

Where can we add this support policy?

1 Like

Whonixnews, sticky on the Qubes subforum and a notice at the top of the Qubes main wiki page?

2 Likes

Added info to the About page to pick this issue up.

Might clean up some more links before fixing up that kernel stuff, but I’ll get there soon enough

1 Like

corridor -> Fixed.

There is one TODO there i.e. non functional bridges config.

Also, there is one table in the FAQ wiki page saying “Ignore for now. Broken since shift” or similar (Tails vs Whonix comparison). Can we just get rid of that or update the links or whatever?

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]