I had the misfortune to update whonix-gateway-18 by accident. I cannot afford it until TCP is merged (this is not a request).
The result is rather unexpected.
After purging ACW (because of privleap conflict), building and installing the package from kicksecure, sdwdate-gui crash on a strict_config_parser module not found.
I compared kicksecure and arraybolt3 packages. arraybolt3 is 9 commits behind kicksecure, but strict_config_parser is not there. After forking, building and installing arraybolt3 version, it works like a charm.
Yes, but why were they not updated ? I had to use apt install -âreinstall to get the ante last version (3:48.2-1). The latest version is 3:48.4-1. Probably not merged yet.
While processing the newnym signal, the button is grayed, and is enabled back after itâs completed. You can check that when custom bridges are used, it takes more time.
While trying a solution to avoid tor_config_sane, I discovered that it depends on helper-scripts, which is called in anon-gw-anonymizer-config/tor-config-sane.
That looks like tor a tortuous way to write a pseudo torrc when /usr/local/etc/torrc.d/40_tor_control_panel.conf is missing.
The way around: in both TCP and ACW, we write a proper torrc template (including DisableNetwork 0) at the very start of of the applications. This is five lines of code. Thus it is transparent to the user and we can remove the redundant if torrc_path_exists in the whole package (firstly, i was astonished by their number).
I cannot see any security issue with this solution, but you are better judges than me.
tor-config-sane has a lot more functionality than writing 1 configuration file. These are stable bash scripts which arenât easily rewritten in python without introducing new bugs.
repair-torrc makes sure /etc/tor/torrc file and /etc/torrc.d/usr/local/etc/torrc.d exists, creates missing configuration files and fixes existing configuration files if these lack %include lines. Itâs also fixing file permissions and file ownership.
If you want to make TCP work with non-Whonix, whatâs the plan for adding an %include line to /etc/tor/torrc?
These scripts shouldnât be trashed for the sake of rewriting them in python.
Instead, if it sounds useful, and if your goal is non-Whonix supportâŚ
Could you move these scripts to TCP;
Use different file paths (not including helper-scripts);
Rename them if needed;
Make them compatible with non-Whonix;
Then call these scripts from python?
If TCP gained non-Whonix support, that would be cool, because then it would gain Kicksecure support.
If bash sounds too complicated, we would probably be able to do this.
TCP at the moment has a lot of GUI dependencies. So it would not be ideal for a CLI / server version. But I think we would be able to deal with this on the packaging level. The single 1 source code repository TCP could generate 2 packages. 1 packages which shipping all files (including scripts such as tor-config-sane and repair-torrc) (tor-control-panel-files) and 1 package (tor-control-panel) shipping no files but Depends: tor-control-panel-files and all GUI dependencies.
Was attributing the issue to the new version of tor-control-panel. Strangely, exiting sdwdate-gui and starting it from a terminal would work.
Well, itâs fixed now, sdwdate-gui working with
which was used since the last post from Patrick.
I did not want to work on the big task ahead before the above issue was resolved.
But there is a condition for starting: merging TCP after reviewing it (it has been thoroughly tested), because I must avoid updating whonix-gateway-18 which reinstall the current kicksecure version.
If you agree, donât forget to remove the ACW package and change line 146 in sdwdate_gui_client.py with from tor_control_panel import tor_status.
However, I have been stuck with a main blocker before even considering testing tor-control-panel in plain Debian.
That is : how to use system wide Tor instead of the bundled Tor in tor browser, without touching tor browser, be it torrc or modifying core parameters with about:config as done in whonix in its own tor browser. There in no way for the package being accepted in Debian (if ever) with a tor browser not installed the standard way (tar file from the torproject or torbrowser-launcher).
After some finally pertinent research including AI and Tails, I can submit a solution (used to write this post).
If not, install Tor
edit /etc/tor/torrc
## Run a SOCKS5 proxy on port 9050
SOCKSPort 127.0.0.1:9050
## Optional but recommended: stream isolation ("may" impact performance and Tor network load)
SOCKSPort 127.0.0.1:9150 IsolateDestAddr IsolateDestPort
## DNS resolution through Tor
DNSPort 127.0.0.1:5353
## Control port for Tor controller tools
ControlPort 9051
## Cookie authentication for control port
CookieAuthentication 1
## Enable Seccomp sandbox (kernel hardening)
Sandbox 1
## User configuration files
%include /etc/tor/torrc.d/
Create a file /etc/profile.d/torbrowser.sh
export TOR_SKIP_LAUNCH=1
Restart Tor: sudo systemctl restart tor@default
Log out or reboot to validate changes in /etc/profile.d
Notes:
DisableNetwork is not in torrc. Seems to be se to 0 by default. It can be set in a .conf file (tested).
Check that debian-tor is in user group (groups user). If not, you may have to add it.
If the tor-control-panel package doesnât modify Tor owned configuration file /etc/tor/torrc, thatâs acceptable by Debian.
tor-control-panel GUI is allowed to modify /etc/tor/torrc any any other file in $HOME etc. Other example GUIs in Debian are doing that. (Examples: gufw, synaptic, software-properties-gtk, grub-customizer. I think.)
Do you want to support configuration of both, system Tor and TBB installed in $HOME?
As for Tor (Browser) configuration files try asking me. For example system Tor not causing conflicts with TBB will be easy to answer.
I manage to install tor in $HOME, not working with TBB though. The different tests are using tor version 0.4.9.9, forcibly or automatically (Debian is at 0.4.9.8). Out of curiosity, I had a look at the torrc sample shipped with the latest version.
Here is what we find at the end of the file:
## Configuration options can be imported from files or folders using the %include
## option with the value being a path. This path can have wildcards. Wildcards are
## expanded first, using lexical order. Then, for each matching file or folder,
## the following rules are followed: if the path is a file, the options from the ## file will be parsed as if they were written where the %include option is. If
## the path is a folder, all files on that folder will be parsed following lexical ## order. Files starting with a dot are ignored. Files on subfolders are ignored.
## The %include option can be used recursively.
#%include /etc/torrc.d/*.conf
Do you want to configure Tor Browser (from TBB archive) to use system Tor (little-t-tor) installed in $HOME?
I might be able to help with that too.
Whatâs the purpose of tor-control-panel configuring pluggable transports for TBB since TBB already has its own internal (supposedly) first class maintained bridge configuration gui wizard?
Here are the environment variables that Whonix is using to configure Tor Browser to use system Tor.
Donât you think it might be frowned up at Debian because itâs a non standard installation ?
We can wait for tor 0.4.9.9. No hurry on my side. It comes with the %include directive, which will help configuring Tor .
BTW, answering an old question:
With tor-0.4.9.8, just by adding %include /etc/tor/torrc.d/*.conf at the end of /etc/tor/torrc and creating 20_default_torrc.conf or whatever in /etc/tor/torrc.d. Not standard neither acceptable at the moment, but it works and is useful for testing before tor-0.4.9.9.
A question: what is the reason you donât merge the latest version of TCP including ACW ? This is the one I use and I have to rebuild it every time after updating whonix-gateway-18.
I can remove the commands.py script to make it kicksecure only, since the general plan is to create a separate package for Debian, with only the necessary helper-scripts included, as suggested by Patrick.
I didnât mean to imply âfeature requestâ. My intention was only a clarification question to find out your goal.
Not my feature request to configure Tor Browser (from TBB archive) to use system Tor (little-t-tor) installed in $HOME. That actually would be rather confusing and unnecessary in my view. Nobody requested that feature gladly.
(But if you did had this as goal I would have helped anyhow to move this forward.)
(Academic only, but no, I donât recall immediately and Debian policy opposing that but not important since not a feature request by anyone.)
Ok.
It is your decision which versions you like to support. No legacy version feature support from my side. If only the latest Tor version was supported by TCP that would suffice.
I think youâre referring to this comment in torrc_gen.py:
## TODO: Leaves a dangling file handle, doesn't handle exceptions,
## doesn't specify encoding, reads the entire content of the file
## multiple times, can be tricked by strings within comments. Fix.
The issue is not that reading an entire file is an issue, the problem is that itâs wasteful to open and read the entire contents of a file to search through its contents, then re-open and re-read the entire contents of that file for the next search. Instead, read the entire contents of the file into a string, close the file (rather than leaving a dangling file handle), and then do your substring searches within the string you just read. That way you can search multiple times but only read the file once.