use Subprocess.jsm to launch tor

[mcs]

In Firefox 49, Mozilla added a new Subprocess.jsm module (they use it to implement the WebExtensions Native Messaging API). Kathy and I have not looked at it closely yet, but this module may provide a better way for Tor Launcher to start and manage the tor process. In particular, Subprocess.jsm provides access to stderr which would allow Tor Launcher to capture all output produced by tor.

Docs:
​http://gecko.readthedocs.io/en/latest/toolkit/modules/subprocess/toolkit_modules/subprocess/

[cypherpunks]

Is this ticket about conversion to WebExtensions?

[mcs]

Replying to cypherpunks:

Is this ticket about conversion to WebExtensions?

No. This ticket is about the possibility of using a JS module to improve Tor Launcher (the JS module happens to have been created to help with the WebExtensions implementation but it could just as well have been created for another purpose).

[arma]

Sounds plausible!

Right now Tor has a hard-coded log to stdout that it adds during startup, but we could -- hm. I was going to say we could make it configurable, but that won't work. I guess Tor Browser could patch Tor before building it, to make that stdout into a stderr?

If you become serious about doing this in Tor Browser, you should open a Tor ticket to let the network team know they should solve it for you somehow. :)

[mcs]

Replying to arma:

Sounds plausible!

Right now Tor has a hard-coded log to stdout that it adds during startup, but we could -- hm. I was going to say we could make it configurable, but that won't work. I guess Tor Browser could patch Tor before building it, to make that stdout into a stderr?

Firefox's Subprocess.jsm allows access to both stdout and stderr, so I don't think the network team needs to make any changes. I just assumed the log was being sent to stderr. Is anything sent to stderr?

Obviously the advantage of this approach (capture tor's stdout) over the one described in ticket:10059#comment:17 is that in most cases something will be logged to stdout even if tor never gets to the point of opening a control port listener.

[arma]

Replying to mcs:

Firefox's Subprocess.jsm allows access to both stdout and stderr, so I don't think the network team needs to make any changes. I just assumed the log was being sent to stderr. Is anything sent to stderr?

Nothing is sent to stderr. It's all stdout by default, unless there is some other log line defined, in which case it is whatever that log line is.

Obviously the advantage of this approach (capture tor's stdout) over the one described in ticket:10059#comment:17 is that in most cases something will be logged to stdout even if tor never gets to the point of opening a control port listener.

Makes sense!

[gk]

Items for September 2017.

[gk]

Items for October 2017

[gk]

Moving tickets over to November.

[gk]

Moving tickets to December 2017

[gk]

Moving tickets to December 2017, for realz.

[gk]

Moving tickets to 2018.

[gk]

Moving tickets to Feb

[gk]

Adding to our March plate.

[gk]

Moving our tickets to April.

[gk]

Moving remaining tickets to May.

[arma]

mcs / gk: is this idea still plausible? Or did it get swept away by Firefox policy changes?

I ask because now that the Tor Browser logs are more accessible, I have resumed being interested in #10059.

[mcs]

Replying to arma:

mcs / gk: is this idea still plausible? Or did it get swept away by Firefox policy changes?

I ask because now that the Tor Browser logs are more accessible, I have resumed being interested in #10059.

It is still a plausible idea, at least for desktop Tor Browser (Firefox on Android does not ship the required Subprocess.jsm module, but maybe tor log capture is already a solved problem on Android; I don't know).

A couple of years ago, Kathy and I experimented with using Subprocess.jsm in Tor Launcher but we ran into a problem where the tor process did not start up right away. Our theory was that the asynchronous nature of the Subprocess.jsm implementation did not play together well with Tor Launcher's use of modal dialogs. We should try again sometime, especially if we are planning to pursue option 3 from #27476 (which presumably would eliminate Tor Launcher's modal startup window).

As I said before, it would be best for the browser capture stdout/stderr rather than doing something like #10059 because there are cases where tor can't start at all (so no control port connection is possible).