Opened 4 years ago

Last modified 2 years ago

#17615 new defect

Tor Browser sets network.proxy.socks_port in an inappropriate way

Reported by: infinity0 Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: mcs, whonix-devel@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I have a wrapper script that looks like this:

$ cat bin/system-torbrowser-launcher 
#!/bin/sh
TOR_CONTROL_PASSWD='"xxx"' TOR_CONTROL_PORT=9051 TOR_SOCKS_HOST=127.0.0.1 TOR_SOCKS_PORT=9050 TOR_SKIP_LAUNCH=1 torbrowser-launcher "$@"

The idea is so that I can switch between TorBrowser's tor instance and the system tor instance with minimal effort. However, currently it doesn't work well:

If I use the wrapper script, TorBrowser will write these two lines:

user_pref("network.proxy.socks_port", 9050);
user_pref("extensions.torbutton.socks_port", 9050);

into prefs.js, so that next time that I don't use the wrapper script, these values are used, and things mess up. If I manually re-edit prefs.js to remove these values, things start working again.

I suggest that, if the environment variables (as indicated in the wrapper script) are not set, then TorBrowser should still unconditionally overwrite the above config variables, but with their default values (i.e. 9150), so that the desired behaviour (ability to switch between tors) works more smoothly.

Child Tickets

Change History (6)

comment:1 Changed 4 years ago by mcs

Cc: mcs added

I am not sure, but I think it may be difficult to fix this in a way that is acceptable to everyone. Ideally, the env vars would only have a temporary effect. Unfortunately, the browser preference at least needs to be modified in order for things to work (network.proxy.socks_port). And I see a problem with your suggestion (reset the pref values if the env vars are not set): if someone has set the preferences to something else without using env vars, we do not want to reset them.

Have you considered using two wrapper scripts?

comment:2 Changed 4 years ago by infinity0

Yes, I see that problem with my original suggestion. Here is an alternate one:

Immediately after setting network.proxy.socks_port from envvar TOR_SOCKS_PORT, register a shutdown hook (e.g. a signal handler for HUP/INT/TERM/etc and whatever else the language gives you) to reset it to the previous value (or no value, if there was no previous).

Does that work better?

comment:3 Changed 4 years ago by proper

Cc: whonix-devel@… added

comment:4 in reply to:  2 Changed 4 years ago by gk

Replying to infinity0:

Yes, I see that problem with my original suggestion. Here is an alternate one:

Immediately after setting network.proxy.socks_port from envvar TOR_SOCKS_PORT, register a shutdown hook (e.g. a signal handler for HUP/INT/TERM/etc and whatever else the language gives you) to reset it to the previous value (or no value, if there was no previous).

Does that work better?

I think so. Patches welcome.

comment:5 Changed 4 years ago by mcs

A complete solution should also monitor those prefs for "manual" changes that are made by the user during the browser session and not restore the original startup value during shutdown if a manual change was made.

comment:6 Changed 2 years ago by mcs

Another person encountered this problem and mentioned it here:
https://lists.torproject.org/pipermail/tor-talk/2017-February/042907.html

Note: See TracTickets for help on using tickets.