Opened 3 years ago
Last modified 7 weeks ago
#21542 new defect
use Subprocess.jsm to launch tor
Reported by: | mcs | Owned by: | brade |
---|---|---|---|
Priority: | Medium | Milestone: | |
Component: | Applications/Tor Launcher | Version: | |
Severity: | Normal | Keywords: | tbb-usability, ff52-esr, TorBrowserTeam201805 |
Cc: | brade, gk | Actual Points: | |
Parent ID: | #10059 | Points: | |
Reviewer: | Sponsor: |
Description
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/
Child Tickets
Change History (19)
comment:1 Changed 3 years ago by
Cc: | gk added |
---|
comment:3 Changed 3 years ago by
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).
comment:4 follow-up: 5 Changed 3 years ago by
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. :)
comment:5 follow-up: 6 Changed 3 years ago by
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.
comment:6 Changed 3 years ago by
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!
comment:7 Changed 2 years ago by
Keywords: | TorBrowserTeam201708 added |
---|
comment:8 Changed 2 years ago by
Keywords: | TorBrowserTeam201709 added; TorBrowserTeam201708 removed |
---|
Items for September 2017.
comment:9 Changed 2 years ago by
Keywords: | TorBrowserTeam201710 added; TorBrowserTeam201709 removed |
---|
Items for October 2017
comment:10 Changed 2 years ago by
Keywords: | TorBrowserTeam201711 added; TorBrowserTeam201710 removed |
---|
Moving tickets over to November.
comment:12 Changed 2 years ago by
Keywords: | TorBrowserTeam201712 added; TorBrowserTeam201711 removed |
---|
Moving tickets to December 2017, for realz.
comment:13 Changed 2 years ago by
Keywords: | TorBrowserTeam201801 added; TorBrowserTeam201712 removed |
---|
Moving tickets to 2018.
comment:14 Changed 22 months ago by
Keywords: | TorBrowserTeam201802 added; TorBrowserTeam201801 removed |
---|
Moving tickets to Feb
comment:15 Changed 21 months ago by
Keywords: | TorBrowserTeam201803 added; TorBrowserTeam201802 removed |
---|
Adding to our March plate.
comment:16 Changed 20 months ago by
Keywords: | TorBrowserTeam201804 added; TorBrowserTeam201803 removed |
---|
Moving our tickets to April.
comment:17 Changed 19 months ago by
Keywords: | TorBrowserTeam201805 added; TorBrowserTeam201804 removed |
---|
Moving remaining tickets to May.
comment:18 follow-up: 19 Changed 7 weeks ago by
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.
comment:19 Changed 7 weeks ago by
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).
Is this ticket about conversion to WebExtensions?