On 2/11/14, 11:23 AM, anonym wrote:
> 11/02/14 02:37, anonym wrote:
> # 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(-)
Thanks for working on this.
> 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.
I think we need to preserve the existing behavior. There are people who
are using TOR_SKIP_LAUNCH and the extensions.torlauncher.start_tor
preference, and I don't think we should break things for them.
We picked the name TOR_CONFIGURE_ONLY for the new behavior because we
thought Tor Launcher would need to exit the browser after the settings
wizard finished. If that is not the case, a name like TOR_CONTROL_ONLY
would be better.
> ...
> 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.
Is there an advantage to avoiding environment variables? They are
already implemented and they work ;)
> # 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:
> ...
I admit that I do not understand everything about the Tails
architecture. It sounds like users can write to the browser's (or
XULRunner's) prefs.js but not to torrc? Is this restriction present to
improve security or for a different reason?
When we designed Tor Launcher, we tried hard to only have Tor settings
stored in one place (torrc). I don't like the idea of "caching" all of
the Tor settings as Tor Launcher preferences, but maybe that is the only
viable solution given your architecture.
> ...
> 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.
Kathy and I will need to review your patches in more detail, but one
comment is that I don't think Tor Launcher should open the network
settings wizard whenever DisableNetwork=1. In fact, to support PTs we
are adding a "Use Default Bridges" option which will require that Tor
Launcher always start Tor with DisableNetwork=1 (so that the correct
bridge configuration can be set before Tor touches the network). Can
you instead ensure that the extensions.torlauncher.prompt_at_startup
pref is set to 'true' before starting Tor Launcher?
--
Mark Smith
Pearl Crescent
http://pearlcrescent.com/
