On 2/11/14, 11:23 AM, anonym wrote:
11/02/14 02:37, anonym wrote: # Tor Launcher in TailsAll 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/ _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
