Tor controller GUI (tor-control-panel)

Development
81

Seconded. We missed you around here :slight_smile:

2 Likes
82

Bug report:

83
84

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.

85

New tor-control-panel contributor wanted!

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

1 Like
86

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

87

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
88
89

Running Tor controller will give message:

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

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

1 Like
91
1 Like
92
1 Like
93

Actually not yet fixed…

1 Like
94

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:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866187

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
95

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.

96

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.

97

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.

98

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
99

Here am I after six years or so, trying to catch up.

After reading the last posts, I think it would be a pity to deprecate ACW and TCP, especially after the work done by Patrick, and thanks to Aaron too.

Actually, TCP depends a lot on ACW. In my opinion, for several reasons that could be discussed later, both packages should be independent.

For this purpose, “The refactoring is easier said than done.”

True. pycharm-community was installed in a standalone vm, where I could clone both repositories in separ

It is hopefully done in

wich is the last commit among many.

2 Likes
100

The previous post was sent accidentally.

More on the process:

  • in pycharm , clone both repositories in separate windows
  • make changes in TCP
  • commit and push from pycharm
  • in whonix-gateway, git pull, build and install the package.
  • poweroff gateway, restart sys-whonix, run TCP and pray.

Considering the number of dependencies from ACW, that explains the number of commits.

Could you review and comment?

2 Likes