11/02/14 02:37, anonym wrote:
> 10/02/14 23:01, intrigeri wrote:
>> Hi,
>>
>> Kathleen Brade wrote (10 Feb 2014 15:17:23 GMT) :
>>> On 2/9/14, 10:21 AM, intrigeri wrote:
>>>> So, now that we agree on something that would satisfy our needs,
>>>> what's the plan? Has anyone allocated time to implement this?
>>>> If someone is planning to do it, is there any ETA?
>>
>>> I think this is easy to add to Tor Launcher; Mark and I can probably
>>> do it in the next couple of days.
>>
>> Awesome!
>>
>> anonym, given you'll be working on bridges support soon, may you
>> please have a look at this idea ASAP, and evaluate how well it could
>> replace our initial plan? From my PoV it looks just great, compared to
>> the initial setup being done in Vidalia, but I might have
>> missed something.
>
> I did some research into this earlier today and have a working,
> standalone POC that can deal with system-wide Tor instances (but it is
> incomplete in some ways that require further discussion). I'm way too
> tired at the moment to do the write up, but I will do it after I've got
> some sleep. In other words, Mark (Mike?), Kathleen and others: please
> don't duplicate work by looking into this until I've posted my results.
Here's my results:
# Tor Launcher in Tails
All in all, not much is necessary to make Tor Launcher able to *only*
control (as opposed to "own", i.e. control + "Tor is started by the
controller, and Tor exits with the controller") a system-wide Tor
instance:
src/application.ini | 13 +++++++++++++
src/chrome/locale/en/torlauncher.properties | 1 +
src/components/tl-process.js | 32
++++++++++++++++++++++++++------
3 files changed, 40 insertions(+), 6 deletions(-)
See attached files for a POC.
Essentially what my changes do is to separate the "starting Tor" and
"control Tor" code, and skip the former if
`extensions.torlauncher.start_tor` is `false`, or if `TOR_SKIP_LAUNCH`
is `1`. The old behaviour of those options is to do absolutely nothing
w.r.t. starting/communicating with Tor, so I suppose they were only
used for debugging. IMHO this new behaviour is better than introducing
`TOR_CONFIGURE_ONLY`, as suggested. If the old behaviour is still
needed we can instead introduce a new option, like `IGNORE_TOR` or
whatever.
# How to start as a stand-alone application in Tails
To test it, add a firewall exception for port 9051 to the `vidalia`
user in `/etc/ferm/ferm.conf`, and run:
git clone https://git.torproject.org/tor-launcher.git
cd tor-launcher
# apply attached patches
sudo -u vidalia TOR_SKIP_LAUNCH=1 TOR_CONTROL_PORT=9051
TOR_CONTROL_COOKIE_AUTH_FILE=/var/run/tor/control.authcookie
xulrunner-17.0 src/application.ini -purgecaches
For the bridge mode behaviour, set `DisableNetwork 1` in torrc first.
(The `-purgecaches` is useful for clearing the XUL runner cache;
otherwise ignore changes made to the source files (at least the `.js`
files) are ignored after the first run. In other words, this is only
relevant for development and can otherwise be skipped.)
We can skip the `TOR_SKIP_LAUNCH` and `TOR_CONTROL_PORT` environment
variables by instead using the corresponding settings in `prefs.js`,
but there is no option corresponding to `TOR_CONTROL_COOKIE_AUTH_FILE`
although a `extensions.torlauncher.control_cookie_path` should be easy
to add. This is only relevant if we prefer to use proper settings
instead of environment variables.
# Problem: settings persistence with a system-wide Tor setup
In Vidalia, settings configured by the user (like `bridge ...`,
`HTTPProxy ...`, etc) persist by being saved in Vidalia's config
(well, I think Vidalia first tries to write the settings to torrc via
`SAVECONF` and falls back to this if it fails, which it does in
Tails), and they are restored as soon as Vidalia establishes control
of Tor. In Tails' current, experimental bridge mode, the obvious race
condition is dealt with by adding an invalid bridge, which effectively
emulated the `DisableNetwork` option (in combination with our custom
Vidalia patches).
In Tor Launcher, settings configured by the user are saved directly in
torrc (via `SAVECONF`), which doesn't fit very well in the Tails
context. With my changes applied, the changes are simply lost whenever
Tor restarts, which will happened for a number of reasons, e.g. for
each new network connection.
This is a fundamental issue that my changes doesn't currently deal
with, and I'm unsure how to proceed. Below are some thoughts on our
options:
* No settings persistence for system-wide Tor instances: While simple
to implement, it's inconsistent with how it works compared to when
Tor Launcher starts Tor, which may confuse users familiar with
TBB. And it's annoying; all bridges have to be re-entered each time
the wireless dies, etc. Also it's inconsistent with how it works in
Vidalia, for whatever that's worth.
* Vidalia-like settings persistence: I suppose we could save the
settings as `extensions.torlauncher.torconf_httpproxy = "IP:PORT"`,
`extensions.torlauncher.torconf_bridges = "[TRANSPORT:]IP:PORT..."`
and so on (note that these would only be used when Tor launcher is
configured to use a system-wide Tor instance). A good question is what
to actually do with the saved settings:
1. Connect immediately when there are saved settings: That'll make it
impossible to reconfigure the settings without restarting Tails,
which will clear the saved settings. For non-Tails users (well,
users with a persistent file system) that want to use Tor Launcher
in a system-wide Tor setup it'll be even more awkward as they have
to delete/modify `prefs.js` manually. I'm not sure how much we
care about that, though.
2. Saved settings are pre-set in the "Configure"-wizard. Quite
convenient, but probably annoying since Tor Launcher would pop up
for each new connection.
3. Add a "Connect using previous settings" button to the network
settings window. Even more convenient, but equally annoying re:
popping up. Additional improvements would be to show a list of
the saved settings on the first page, and/or combined 2 above.
Some additional options via environment variables that may be useful:
- `FORCE_RESTORE_SETTINGS`: when set we'd force the behaviour of 1
above. This could be useful to relieve the users of a Tor Launcher
pop up when we detect that we're just *reconnecting* to the same
network (assuming we can easily detect that via NetworkManager).
- `FORCE_SHOW_NET_CONFIG`: when set this would always show the
network configuration as if one had clicked the "Configure"
button, which could be useful if we want to provide a desktop
shortcut (or whatever) that can be used to change the settings
at any point (or at all if we go with 1 above).
If we can agree on what the right thing to do with all this is, and I
haven't missed anything big, I feel confident that we can drop Vidalia
and have bridge mode implemented using Tor Launcher in Tails 0.23.
Cheers!
>From 7095689ce333c1e56897daaac0c874bee2b94419 Mon Sep 17 00:00:00 2001
From: Tails developers <amnesia@???>
Date: Mon, 10 Feb 2014 23:37:06 +0100
Subject: [PATCH 1/3] Split Tor process starting code from control code.
---
src/chrome/locale/en/torlauncher.properties | 1 +
src/components/tl-process.js | 28 ++++++++++++++++++++++-----
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/src/chrome/locale/en/torlauncher.properties b/src/chrome/locale/en/torlauncher.properties
index 483ce43..1221701 100644
--- a/src/chrome/locale/en/torlauncher.properties
+++ b/src/chrome/locale/en/torlauncher.properties
@@ -7,6 +7,7 @@ torlauncher.tor_exited=Tor unexpectedly exited.
torlauncher.please_restart_app=Please restart this application.
torlauncher.tor_controlconn_failed=Could not connect to Tor control port.
torlauncher.tor_failed_to_start=Tor failed to start.
+torlauncher.tor_control_failed=Failed to take control of Tor.
torlauncher.tor_bootstrap_failed=Tor failed to establish a Tor network connection.\n\n%S
torlauncher.unable_to_start_tor=Unable to start Tor.\n\n%S
diff --git a/src/components/tl-process.js b/src/components/tl-process.js
index 660588d..d70216f 100644
--- a/src/components/tl-process.js
+++ b/src/components/tl-process.js
@@ -88,9 +88,12 @@ TorProcessService.prototype =
this.mObsSvc.addObserver(this, kOpenNetworkSettingsTopic, false);
this.mObsSvc.addObserver(this, kUserQuitTopic, false);
this.mObsSvc.addObserver(this, kBootstrapStatusTopic, false);
+ this.mTorProcessStatus = this.kStatusUnknown;
if (TorLauncherUtil.shouldStartAndOwnTor)
this._startTor();
+
+ this._controlTor();
}
else if ("quit-application-granted" == aTopic)
{
@@ -261,8 +264,6 @@ TorProcessService.prototype =
// Private Methods /////////////////////////////////////////////////////////
_startTor: function()
{
- this.mTorProcessStatus = this.kStatusUnknown;
-
var isInitialBootstrap =
TorLauncherUtil.getBoolPref(this.kPrefPromptAtStartup);
@@ -340,7 +341,24 @@ TorProcessService.prototype =
p.runwAsync(args, args.length, this, false);
this.mTorProcess = p;
this.mTorProcessStartTime = Date.now();
+ }
+ catch (e)
+ {
+ this.mTorProcessStatus = this.kStatusExited;
+ var s = TorLauncherUtil.getLocalizedString("tor_failed_to_start");
+ TorLauncherUtil.showAlert(null, s);
+ TorLauncherLogger.safelog(4, "_startTor error: ", e);
+ }
+ }, // _startTor()
+
+
+ _controlTor: function()
+ {
+ var isInitialBootstrap =
+ TorLauncherUtil.getBoolPref(this.kPrefPromptAtStartup);
+ try
+ {
this._monitorTorProcessStartup();
if (isInitialBootstrap)
@@ -378,11 +396,11 @@ TorProcessService.prototype =
catch (e)
{
this.mTorProcessStatus = this.kStatusExited;
- var s = TorLauncherUtil.getLocalizedString("tor_failed_to_start");
+ var s = TorLauncherUtil.getLocalizedString("tor_control_failed");
TorLauncherUtil.showAlert(null, s);
- TorLauncherLogger.safelog(4, "_startTor error: ", e);
+ TorLauncherLogger.safelog(4, "_controlTor error: ", e);
}
- }, // _startTor()
+ }, // controlTor()
_monitorTorProcessStartup: function()
{
--
1.7.10.4
>From a1150791bfddbb7ef2adf251f53b99ae7f167aed Mon Sep 17 00:00:00 2001
From: Tails developers <amnesia@???>
Date: Tue, 11 Feb 2014 14:44:01 +0100
Subject: [PATCH 2/3] Always open network settings if DisableNetwork is set.
---
src/components/tl-process.js | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/components/tl-process.js b/src/components/tl-process.js
index d70216f..cc234df 100644
--- a/src/components/tl-process.js
+++ b/src/components/tl-process.js
@@ -360,8 +360,10 @@ TorProcessService.prototype =
try
{
this._monitorTorProcessStartup();
+ var networkDisabled =
+ this.mProtocolSvc.TorGetConfBool("DisableNetwork", true).retVal;
- if (isInitialBootstrap)
+ if (isInitialBootstrap || networkDisabled)
{
if (this.mProtocolSvc)
this._openNetworkSettings(true); // Blocks until dialog is closed.
--
1.7.10.4
>From d759f811b78c235388d551d30acab181c0d9c7b7 Mon Sep 17 00:00:00 2001
From: Tails developers <amnesia@???>
Date: Tue, 11 Feb 2014 00:02:22 +0100
Subject: [PATCH 3/3] Add application.ini suitable for standalone XUL.
---
src/application.ini | 13 +++++++++++++
1 file changed, 13 insertions(+)
create mode 100644 src/application.ini
diff --git a/src/application.ini b/src/application.ini
new file mode 100644
index 0000000..afccafc
--- /dev/null
+++ b/src/application.ini
@@ -0,0 +1,13 @@
+[App]
+Vendor=TorProject
+Name=TorLauncher
+Version=0.1
+BuildID=20140210
+ID=tor-launcher@???
+
+[Gecko]
+MinVersion=17.0.0
+MaxVersion=*.*.*
+
+[Shell]
+Icon=icon.png
--
1.7.10.4
