Hey folks,
nmago is continuing work on the crash reporter, and ran into some proxy problems. He's trying to get the proxy settings inside the crash reporter tool but the crash reporter tool can't read Firefox's proxy settings!
Upstream this is talked about in https://bugzilla.mozilla.org/show_bug.cgi?id=1388897 https://bugzilla.mozilla.org/show_bug.cgi?id=1333125 and he asked here: https://groups.google.com/forum/#!topic/mozilla.dev.platform/opiD1Rz-e68
I'm wondering if in Tor Browser we can run around Firefox' lack of support here and:
A) If we hardcode the proxy settings (fixed port) than nmago can just hardcode it in the crash reporter OR B) If we choose a random port, if we can make that information available to the crash reporter somehow.
If we do (B), is the port chosen written out into a torrc file he could read? Or is it determined on startup and only held in memory? This gets tricky because we don't really want to write anything to disk and other IPC mechanisms (Environment Variables) are concerning... (but maybe acceptable from our threat model?)
-tom
On 11/8/17 12:58 PM, Tom Ritter wrote:
Hey folks,
nmago is continuing work on the crash reporter, and ran into some proxy problems. He's trying to get the proxy settings inside the crash reporter tool but the crash reporter tool can't read Firefox's proxy settings!
Upstream this is talked about in https://bugzilla.mozilla.org/show_bug.cgi?id=1388897 https://bugzilla.mozilla.org/show_bug.cgi?id=1333125 and he asked here: https://groups.google.com/forum/#!topic/mozilla.dev.platform/opiD1Rz-e68
I'm wondering if in Tor Browser we can run around Firefox' lack of support here and:
A) If we hardcode the proxy settings (fixed port) than nmago can just hardcode it in the crash reporter OR B) If we choose a random port, if we can make that information available to the crash reporter somehow.
The code that sets the browser proxy preferences is here: https://gitweb.torproject.org/torbutton.git/tree/src/components/startup-obse... (within the setProxySettings() function).
It checks some environment variables, but usually it ends up asking Tor Launcher for the settings (which are determined by TL before it starts the tor daemon). The gory details of what Tor Launcher does can be found in comments and code here: https://gitweb.torproject.org/tor-launcher.git/tree/src/components/tl-protoc...
Note that in some cases a Unix domain socket is used instead of a TCP port.
If we do (B), is the port chosen written out into a torrc file he could read? Or is it determined on startup and only held in memory? This gets tricky because we don't really want to write anything to disk and other IPC mechanisms (Environment Variables) are concerning... (but maybe acceptable from our threat model?)
I am not sure what the best solution is, but I assume the idea is to use the already running tor deamon to submit crash reports. Will the tor daemon still be running after the browser process crashes (Tor Launcher uses the TAKEOWNERSHIP control port command to arrange for tor to shutdown when the firefox process does). Also note that recent versions of Tor Launcher pass the SocksPort info via the command args when starting tor, so in most cases the SOCKSPort info won't be written to torrc.
On 9 November 2017 at 08:35, Mark Smith mcs@pearlcrescent.com wrote:
I am not sure what the best solution is, but I assume the idea is to use the already running tor deamon to submit crash reports. Will the tor daemon still be running after the browser process crashes (Tor Launcher uses the TAKEOWNERSHIP control port command to arrange for tor to shutdown when the firefox process does).
That is a good question. We had this working before, but then we discovered this new need-the-proxy-settings problem. nmago, what have you seen? Does the tor process shut down before the crash reporter can do its thing?
One way you can test this is to hardcode the crash reporter to get the proxy settings from an environment variable, launch tor browser, figure out the listening port using netstat, and then set the environment variable to the correct port.
-tom
Hi!
Thank you for the answer, Mark!
Does the tor process shut down before the crash reporter can
do its thing?
No, it doesn't (it waits for crash reporter), I also checked Google breakpad, it uses libcurl, so it supports SOCKS, I hardcoded our IP and port, but still haven't built it.
Sorry for delay, I busy with internship interview stuff :/
Kind regards, Nur-Magomed (nmago)
2017-11-11 20:31 GMT+03:00 Tom Ritter tom@ritter.vg:
On 9 November 2017 at 08:35, Mark Smith mcs@pearlcrescent.com wrote:
I am not sure what the best solution is, but I assume the idea is to use the already running tor deamon to submit crash reports. Will the tor daemon still be running after the browser process crashes (Tor Launcher uses the TAKEOWNERSHIP control port command to arrange for tor to shutdown when the firefox process does).
That is a good question. We had this working before, but then we discovered this new need-the-proxy-settings problem. nmago, what have you seen? Does the tor process shut down before the crash reporter can do its thing?
One way you can test this is to hardcode the crash reporter to get the proxy settings from an environment variable, launch tor browser, figure out the listening port using netstat, and then set the environment variable to the correct port.
-tom
-
Mark Smith -
Nur-Magomed -
Tom Ritter