Tor controller GUI (tor-control-panel)

It was really crashing on any bridge selection in “Configure”.

Will have to disable snowflake option too, until a solution is found.


Wow, glad to see you’re back! Thanks for the commit, merged! :slight_smile:


Seconded. We missed you around here :slight_smile:


Bug report:

Keeping message Tor control panel Tor Status = Connected to the Tor network is confusing as it doesn’t reflect the actual state. Users expect this to be updated in real time when they open tor-control-panel.

New tor-control-panel contributor wanted!

tor-control-panel will be deprecated unless a new contributor is found.

1 Like

@troubadour @iry anybody gonna work on this? (specially as a plus to support wayland)

I was looking into tor-control-panel, because it could serve as base for safely editing the tor configuration files.
I am far from ready to contribute to Qt applications but I have some ideas to do long term:

  • let the user edit the torrc with a gui text editor after clicking on the Files (Logs) → torrc. Then it could verify the file and give 3 options → edit again, exit without saving, force save configuration. A gui for vitor
  • would very much like to use this on plain debian, and it currently breaks because it is creating unreadable files on /etc/torrc.d and /usr/local/etc/torrc.d. I read the thread, but I still find creating this folder uncessesary for plain debian, it does not work anyway.
  • it could be a gui send command for tor-ctrl, so user types commands directly on tor-control-panel and see responses on a qt application also.

Anyway, don’t put much hope as I am still learning and this is not my priority.

1 Like

Running Tor controller will give message:

user@host:~$ tor-control-panel 
/usr/lib/python3/dist-packages/tor_control_panel/ SyntaxWarning: "is" with a literal. Did you mean "=="?
  if self.tor_controller.get_conf('DisableNetwork') is '1':
1 Like

Feature Request: Make Tor Control Panel compatible with non-whonix environment otherwise remove from kicksecure repository.

1 Like
1 Like
1 Like

Actually not yet fixed…

1 Like

Debian (Non-Whonix / Non-Kicksecure) support for anon-connection-wizard (ACW) and/or tor-control-panel (TCP) is difficult.

Debian doesn’t support /etc/torrc.d/*.conf drop-in folder yet:

Adding that folder through ACW / TCP would lead to AppArmor issues and therefore Tor failing to start.

ACW / TCP requires that. An alternative would be directly modifying /etc/tor/torrc but that is complex, error-prone. Therefore I won’t implement that. /etc/torrc.d/*.conf drop-in folder is in my opinion sustainable way forward.

Even if Debian supported /etc/torrc.d/*.conf drop-in folder, Whonix uses /usr/local/etc/torrc.d/*.conf for Qubes(-Whonix) support. Supporting both, /etc/torrc.d and /usr/local/etc/torrc.d folders would also make the code more complex, more time consuming to implement, test. Given that there are no co-maintainers investing brain power into this, Debian (non-Kicksecure) support probably won’t happen.

Kicksecure support is possible. For that the GitHub - Whonix/anon-gw-anonymizer-config (which handles the required AppArmor modifications to allow Tor reading /etc/torrc.d and /usr/local/etc/torrc.d folders) needs to be ported to Kicksecure which will happen at a later time. The name of that package might become anonymizer-config-dist or so. Debian (non-Kicksecure) users being OK with folder /usr/local/etc/torrc.d and installing anonymizer-config-dist could then even use ACW / TCP.

ACW / TCP in the future will probably depend on anonymizer-config-dist.

1 Like

tor-control-panel (TCP) and anon-connection-wizard (ACW) have some code duplication.

Also TCP and ACW have different code to generate torrc.

This makes maintenance difficult.

Merge features of both tools into one. Thats the best thing.

Since they need to be compatible with wayland, so code refurbished need to be done anyway.

Further development is required. That’s why I mentioned that. TCP package could Depends: on ACW package for shared functionality. The refactoring is easier said than done.

Both, ACW and TCP have been contributed. These contributors are now inactive.

I cannot take over maintenance of all previously contributed functionality. Therefore in the long run, ACW and TCP are at risk of deprecation / removal from Whonix.

This is a bit better now but the bridge/proxy feature would be better if removed from TCP and solely implemented in ACW to reduce code duplication. That would help so only 1 tool needs to be tested, not both.

1 Like