Tor controller GUI (tor-control-panel)

troubadour · August 20, 2018, 7:00pm

Yes, probably. Have pushed a few commits in tor-control-panel.

Left with an issue in sdwdate-gui-qubes when /var/run/tor/ is deleted.

Patrick · August 20, 2018, 9:31pm

All merged.

Btw also all readme’s of all packages updated.
Radically simplified.
(using generic readme developer-meta-files/README_generic.md at master · Kicksecure/developer-meta-files · GitHub)

That’s a good question. I keep wondering. Often I try to foresee what would happen on disk errors where parts of the files don’t exist.
Maybe not situations created by developers but created by users.
An onion-grater corner case is that it fails to start if networking does not come up (due to some unidentified update bug). Then even if networking gets manually restarted, the system still doesn’t work and no hint to restart onion-grater. So ideally onion-grater could gracefully handle non-existing network and wait for it.

Not great but ok. Could instruct user to do something (start tor-control-panel, if installed, on gateway).

The refusal to start is very much worth fixing. We rely on it as a diagnosis tool. While it doesn’t have to be able to fix all things that users can mess up, it’s good if it at least hints whats wrong.

However we probably should not go as far as fixing a system where the user deleted /usr/share/tor/tor-service-defaults-torrc in Whonix.

troubadour · August 22, 2018, 7:12pm

Was done a couple fo days ago.

Sorry I did not describe the commits.

Probably overkill. But if we had the template, that would be a matter of copying a file.

A logic fix.

Patrick · August 23, 2018, 10:17am

tor_is_enabled = tor_status.tor_status() == ‘tor_enabled’ and not
tor_status.tor_status() == ‘missing_disablenetwork_line’

tor_status.tor_status() just returns one keyword. Or could it be
‘tor_enabled’ and at the same time ‘missing_disablenetwork_line’?

I doubt it can be ‘missing_disablenetwork_line’ and ‘tor_enabled’ at the
same time? So I don’t understand that logic anyhow.

troubadour · August 23, 2018, 9:27pm

Yes, the logic is flawed, again.

There is an easy fix, just returning tor_disabled if the DisableNetwork line is missing. Or there is more…

tor_status.py does not parse all the files in /etc/torrc.d. If a line DisableNetwork 1 is written in the user’s torrc file (why not ?), we have no way to know it. Tor, sdwdate and whonixcheck will be aware though.

Also, if the line is commented, tor_status.py cannot parse it either. However, anon-connection-wizard can deal with the commented line on reboot, because it rewrites torrc in anon-connection-wizard.py

Patrick · August 24, 2018, 7:42am

Because anon-gw-anonymizer-config/torrc.anondist at master · Whonix/anon-gw-anonymizer-config · GitHub only uses /etc/torrc.d/95_whonix.conf which only uses:

%include /usr/local/etc/torrc.d/40_tor_control_panel.conf
%include /usr/local/etc/torrc.d/50_user.conf

We’re not really using whole torrd.d. Why? Because torrc.d/*.conf isn’t implemented yet (Tor Project ticket exists- Parse only .torrc files in torrc.d directory (#25140) · Issues · Legacy / Trac · GitLab). Without only parsing *.conf files with appendix like ~ (graphical editor backup files) and .dpkg-old would also be parsed leading to unexpected behavior.

So the ideal way would be “same way like Tor does”. From the Tor startup command, to tor-service-defaults-torrc, to /etc/tor/torrrc and always evaluating the %include statements.

Bash pull request in progress.

//cc @iry

Patrick · August 24, 2018, 1:55pm

https://github.com/Whonix/whonixsetup/commit/5eecfc30e4563ae4f6cc867acc72589a8cd20902

troubadour · August 24, 2018, 10:09pm

It should be done in

I created files containing DisableNetwork 1 with any appendix (.anything or .conf.anything) in torrc.d. glob parses only .conf files.

It is a big commit, some changes in torrc/torrc.d path in several files.
In the maze, I have commented this part:

    ### start Tor
    #command = 'systemctl --no-pager restart tor@default'
    #tor_status_code = call(command, shell=True)

    #if tor_status_code != 0:
        #return 'cannot_connect', tor_status_code

    ### we have to reload to open /var/run/tor/control and create /var/run/tor/control.authcookie
    #command = 'systemctl reload tor@default.service'
    #tor_status_code = call(command, shell=True)

    #command = 'systemctl --no-pager status tor@default'
    #tor_status_code= call(command, shell=True)

    #if tor_status_code != 0:
        #return 'cannot_connect', tor_status_code

    #return 'tor_enabled', tor_status_code

tor-control-panel is restarting Tor after any action, and it looks like that today we do not have to reload Tor after enabling the network. Tested after reboot.

troubadour · August 25, 2018, 4:43pm

Forget the last commit. Will revert. I was carried away in coding, without reading closely enough.

troubadour · September 2, 2018, 7:39pm

On the other hand, do we have to wait for https://trac.torproject.org/projects/tor/ticket/25140 to implemented .conf parsing only? Isn’t it the default extension for the .d mechanism?

In https://github.com/Whonix/anon-shared-helper-scripts/pull/3#issuecomment-377913469, you wrote

Parsing only *.conf rather than * is very important (and an easy code change) indeed.

That’s what I believe too. The last commit in tor-control-panel just implements that.

But we have to parse .conf in tor_enabled_check, or whonixcheck will complain if a file with a ~ or whichever extension exist in torrc.d.

The real thing, parsing as Tor does, would have to be done in a new python script, as you suggest.

Patrick · September 3, 2018, 3:53am

Yes.

Unfortunately not. Tor’s %include parses everything.

Patrick · September 16, 2018, 10:14am

Qubes Debian VM. Detects Tor disabled if it is not.

cat /etc/tor/torrc /etc/torrc.d/40_tor_control_panel.conf /etc/torrc.d/50_user.conf

.

%include /etc/torrc.d/40_tor_control_panel.conf
%include /etc/torrc.d/50_user.conf
# Do not edit this file!
# Please add modifications to the following file instead:
# /etc/torrc.d/50_user.conf
Log notice file /var/run/tor/log
# Tor user specific configuration file
#
# Add user modifications below this line:
############################################

The network is disabled.

A line DisableNetwork 1 exists in torrc
The network can be enabled with:

Tor controller cannot be constructed.This is very likely because you have a "DisableNetwork 1" line in some torrc file(s). Please manually remove or comment those lines and then run anon-connection-wizard or restart Tor.

"DisableNetwork 1 doesn’t lead to Tor control socket unavailable.

Patrick · December 15, 2018, 5:34am

github.com

Kicksecure/tor-control-panel/blob/master/usr/lib/python3/dist-packages/tor_control_panel/torrc_gen.py#L27


      
          bridges_default_path = '/usr/share/tor-control-panel/bridges_default'
          
          
command_useBridges = 'UseBridges 1\n'
          command_use_custom_bridge = '# Custom Bridge is used:'
          
          
bridges_command = [ 'ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy\n',
          
          
                    'ClientTransportPlugin snowflake exec /usr/bin/snowflake-client -url https://snowflake-broker.azureedge.net/ -front ajax.aspnetcdn.com -ice stun:stun.l.google.com:19302 -max 3\n',
          
          
                    'ClientTransportPlugin meek_lite exec /usr/bin/obfs4proxy\n',
                              'ClientTransportPlugin scramblesuit exec /usr/bin/obfs4proxy\n',
                              'ClientTransportPlugin fte exec /usr/bin/fteproxy --managed\n']
          
          
bridges_type = ['obfs4', 'snowflake', 'meek-azure', 'scramblesuit', 'fte', 'plain']
          
          
bridges_display = ['obfs4 (recommended)', 'snowflake',
                             'meek-azure (works in China)', 'plain']
          
          
#meek_amazon_address = 'a0.awsstatic.com\n'
          meek_azure_address = 'ajax.aspnetcdn.com\n'

We don’t have snowflake / /usr/bin/snowflake-client in Whonix. Doesn’t work for me. Did this ever work? Should be removed if broken.

meek: does any meek still work or should be removed? //cc @iry

iry · December 15, 2018, 5:37am

It works as long as we extract the snowflake executable from TBB to /usr/bin/snowflake-client. However, snowflake is never packaged into Debian. I guess we can leave it here and wait for snowflake getting into Whonix or Debian?

Patrick · December 15, 2018, 6:23am

I am not offended by keeping inactive code in. On the contrary, if it
helps, I am a big fan of it. Even if others by convention don’t like that.

The problem is that when users try this the snowflake option, it’s
broken. Tor fails to start due to the missing binary. So it’s a
usability bug.

I guess we can leave it here and wait for snowflake getting into
Whonix or Debian?

Whonix: Not realistic at this point. In theory we could slightly modify
tb-updater and download TBB to Whonix-Gateway and keep it updated but no
manpower to implement.

iry · December 15, 2018, 6:36am

I see! This can be easily fixed, we simply hide this option from user:

Patrick · December 15, 2018, 7:25am

This is tor-control-panel thread. So tor-control-panel issue. Didn’t notice this is an ACW issue as well.

I guess the tor-control-panel vs ACW issue will be sorted once the code is merged and reused/shared.

Hide snowfalke optoin from user · irykoon/anon-connection-wizard@6f2ce2f · GitHub merge not easy. Could you please merge Whonix/master or rebase on Whonix/master beforehand?

iry · December 15, 2018, 7:32am

I did a pull request just now: Support new Pluggable Transport Snowflake by irykoon · Pull Request #22 · Kicksecure/anon-connection-wizard · GitHub

troubadour · July 6, 2019, 9:24pm

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

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

Patrick · July 7, 2019, 12:41am

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