OnionShare Whonix integration development discussion

Onionshare could be simple. Since apparently is uses Tor’s ControlPort, thanks to Control Port Filter Proxy (onion-grater, a Tor Control Port Filter Proxy - filtering dangerous Tor Control Port commands - Design Documentation - Whonix) and thanks to dummytor (Dev/anon-ws-disable-stacked-tor - Whonix), probably no changes on Whonix-Workstation are required.

On Whonix-Gateway, CPFP needs an additional configuration snippet. Check CPFP’s log for commands, that onionshare not yet has access to.

tail -f /var/log/controlportfilt.log

A quick look at onionshare’s code tells me, that the following instructions could be sufficient to get it started:

I might try myself at some point. I am waiting for a secure method to get the software:

This would require some code changes in CPFP. Globing matches instead of exact matches for the whitelist, because onionshare uses for example.

SETCONF HiddenServiceDir="/tmp/onionshare_hidden_service_52825" HiddenServicePort="80"

But that’s not the biggest issue. I did some experimental CPFP changes on my hdd and came as far as this.

onionshare README.md

Calculating SHA1 checksum. Connecting to Tor control port to set up hidden service on port 52825. Traceback (most recent call last): File "/usr/bin/onionshare", line 10, in <module> onionshare.main() File "/usr/lib/python2.7/dist-packages/onionshare/onionshare.py", line 146, in main onion_host = get_hidden_service_hostname(port) File "/usr/lib/python2.7/dist-packages/onionshare/onionshare.py", line 57, in get_hidden_service_hostname return open(hostname_file, 'r').read().strip() IOError: [Errno 2] No such file or directory: '/tmp/onionshare_hidden_service_52825/hostname'

The problem is, that to get the .onion address, onionshare has to read a file on the hdd. But Tor runs on a different system than onionshare. Tor lacks a feature to set/get onion key and hostname through Tor Control Protocol:

Same issue as with torsion:


  • Maybe a --tempfolder option could be included into onionshare + give Whonix-Workstation access to some folder on Whonix-Gateway. Very hacky. Probably not worth it.
  • Modify onionshare to use an existing .onion address instead of an dynamically created one. (Then it would be similar to Onion Services - Whonix or Instant Messenger Chat instructions.)
  • Money/time would be better spent to get the missing features implemented into Tor. Unfortunately, the latter is outside my current abilities.

Made a feature request:

Instructions on getting onionshare to work in Whonix progressed far although they are still unfinished: Next - Whonix

Help would be welcome with the following two required control port filter python features that are missing to add onionshare support.

…since I am busy with various stuff, and since @troubadour is busy with various stuff and our new…

source forge help wanted post: https://sourceforge.net/p/forge/helpwanted/programmers/thread/34928768/

Lots of progress has been made. There is a very good chance it will work in Whonix 14.

For reference:

maybe future work:

1 Like

ongoing discussion:
decide if we should install onionshare by default in Whonix 14
⚓ T595 install onionshare by default in Whonix 15

2 posts were split to a new topic: hide torbrowser-launcher inside Whonix start menu

Won’t make it into Whonix 14. Unfortunately, it is not available from Debian stretch.


Does anyone know why?

Weird. Its on every Debian version except current stable…

Attempts to build it on Stretch are failing:


Tails is using the onionshare from sid:
It seems Tails is enabling all the repository enabled and then use pin-priority to control where should a package be download and installed from.

cat config/chroot_apt/preferences:

Package: onionshare
Pin: release o=Debian,n=sid
Pin-Priority: 999

Is this a feature that is nice to have in Whonix? Or do we have any concern causing us not to adopt this approach ?


As far I know, Tails doesn’t support full upgrades. Only point release
upgrades. So not comparable wrt upgrades and pinning.

Apt pinning is too complicated and must be avoided. Reasoning:


For those who would like to use or try onionshare…

After cloning Micah’s repository and building the package, there was an issue running it.

I don’t know which version of onionshare the .d onion-grater white list 40_onionshare.yml was written for, but with version 1.2 (as stated in the GUI), I had to add a line to the ADD_ONION command.

Mimicking NEW:BEST Port=

      - pattern: 'NEW:RSA1024 Port=80,(176[0-5][0-9])'
        replacement: 'NEW:RSA1024 Port=80,{client-address}:{} Flags=DiscardPK'

Btw for those who don’t know (information not connected here), instructions can be found here:

Next - Whonix


0.9.2 most likely.

1 Like
1 Like

It seems onionshare will land on stretch-backports but not stretch:

1 Like

A regression about showing the Whonix advice if onion-grater profile is not active yet in Whonix 15 / debian buster based.

Added support for OnionShare in “bundled Tor” configuration which is the default in Debian buster version of OnionShare.

Installing onionshare issue on Whonix 14 "there was an error with Tor: SET EVENTS rejected HS_DESC" · Issue #829 · onionshare/onionshare · GitHub

This will come through Whonix 15 package upgrades at some point in future.

1 Like

Over on tor-dev, this thread makes it very clear that v2 onions are plain dangerous for various reasons.


I note this because the current version of OnionShare from Debian buster (v1.3.2) installed in Whonix defaults to legacy v2 as you can see in my screenshots recently added.

(Which is funny, since if you have a much later Tor version >3.5.X like that provided by Whonix, it is apparently meant to default to v3? Maybe that is only for later OnionShare software version?)

So I guess this might be something where we recommend users default to a later installed version from Sid? (v2.2-2) and take their chances. Bullseye has v2.2. Otherwise they are at real risk of having their ass hacked by capable adversaries.