meek profile error after browser restarts (e.g., after update or add-on installation)
While testing an in-browser update of TB 4.0a2 to TB 4.0a3 with meek enabled, the meek browser profile seems to be damaged after the update. brade and I observed this on both Mac OS and Windows 7. Steps to reproduce:
-
Configure TB 4.0-alpha-2 with the meek-amazon transport.
-
Use the in-browser updater to update to 4.0-alpha-3 (for testing, we are hosting the XML update manifest and MAR files on our own server and setting app.update.url.override to point to them).
-
After restart, the Tor Status window will make no progress and an error alert that reads "Profile Missing. Your Firefox profile cannot be loaded. It may be missing or inaccessible."
Strangely, restarting the browser a second time seems to fix the problem.
Activity
The meek-http-helper profile isn't listed in profiles.ini (on purpose). I wonder if that can be related? Here is my profiles.ini with 4.0-alpha-2:
[General] StartWithLastProfile=1 [Profile0] Name=default IsRelative=1 Path=profile.default Default=1What does yours look like after starting the browser a second time? If you run
./Browser/firefox -P, is the meek-http-helper profile listed? For me it only shows "default".
Replying to dcf:
The meek-http-helper profile isn't listed in profiles.ini (on purpose). I wonder if that can be related? Here is my profiles.ini with 4.0-alpha-2: ... What does yours look like after starting the browser a second time? If you run
./Browser/firefox -P, is the meek-http-helper profile listed? For me it only shows "default".My profile.ini is the same as yours after updating to 4.0-alpha-3, so I do not think that is the problem.
Today on Mac OS after I saw the "Profile Missing" error, I restarted the browser again and the Tor Launcher configuration wizard was displayed (presumably because the Tor bootstrap failed the last time the browser was started). But at the same time, a "Select Your Add-ons" window was displayed, asking me to confirm that I wanted the meek HTTP helper add-on the be enabled (I will attach a screenshot). After I dismiss that window and then click "Connect" in the Tor Launcher wizard, everything works fine. Upon subsequent restarts everything is also OK.
I wonder if the problem occurs during/after an update because the hidden meek client browser does not get shutdown while the updater is updating files. Or maybe the shutdown is not fast enough. Tor Launcher issues a TAKEOWNERSHIP control port command and relies on tor to shut itself down when the main browser exits.
-
brade and I just came up with another way to possibly cause this kind of problem. We tried it, and indeed the same problem occurs. No update is required. Just follow these steps:
-
Install a new TB 4.0-alpha-3 browser and configure it to use meek.
-
Go to Tools|Add-ons and install a Firefox add-on that requires a restart. We used our Page Saver add-on but any add-on that requires a restart should work.
-
Click "Restart Now" within the Add-ons window after the add-on has been downloaded. This will case the browser to restart quickly. Then you will see the "Profile Missing" alert.
-
I found this article describing select-addons.png:
- https://blog.mozilla.org/addons/2011/08/11/strengthening-user-control-of-add-ons/ There are some prefs related to it, maybe including extensions.shownSelectionUI and extensions.autoDisableScopes.
It might have to do with how the extension is enabled. All I did was set this in user.js:
user_pref("extensions.enabledAddons", "meek-http-helper@bamsoftware.com:1.0");I notice that profile.default does something different. I don't know how it gets set, but my Browser/TorBrowser/Data/Browser/profile.default/prefs.js has
user_pref("extensions.enabledAddons", "torbutton%40torproject.org:1.6.12.1,tor-launcher%40torproject.org:0.2.7.0,%7B73a6fe31-595d-460b-a920-fcc0f8843232%7D:2.6.8.42,https-everywhere%40eff.org:5.0development.0"); user_pref("extensions.installCache", "[{\"name\":\"app-profile\",\"addons\":{\"{73a6fe31-595d-460b-a920-fcc0f8843232}\":{\"descriptor\":\"/home/david/tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/extensions/{73a6fe31-595d-460b-a920-fcc0f8843232}.xpi\",\"mtime\":1411627039000},\"torbutton@torproject.org\":{\"descriptor\":\"/home/david/tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/extensions/torbutton@torproject.org.xpi\",\"mtime\":946684800000},\"tor-launcher@torproject.org\":{\"descriptor\":\"/home/david/tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/extensions/tor-launcher@torproject.org.xpi\",\"mtime\":946684800000},\"https-everywhere@eff.org\":{\"descriptor\":\"/home/david/tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/extensions/https-everywhere@eff.org\",\"mtime\":1411627057000,\"rdfTime\":946684800000}}}]");Here is a possibly related blog comment.
https://blog.torproject.org/blog/tor-browser-405-released#comment-90721
I used the auto-updater to update from Tor Browser 4.0.4 to 4.0.5 with Linux 32bit on Debian Wheezy. After auto-updating I click the 'restart' button. Tor restarts and then the configuration window comes up asking me if I want to connect directly to Tor or use a bridge. 4.0.4 was configured to use the meek-google bridge. I don't click on any configure buttons and Tor 4.0.5 gets to 100% connection status and connects to meek-google bridge automatically, but Tor web browser doesn't launch and the configure window just sits there blocking Tor web browser from launching. So I close the configure window, which disconnects Tor. Then relaunch Tor, but this time the configure window doesn't come up and the Tor web browser launches when the connection status gets to 100%. A window pops up saying "Tor has been successfully updated."
-
I saw this again today when updating from TB 4.0.8 to 4.5.1 on Windows 7 with meek-azure enabled. Now that a lot of people are using meek, I am worried that many people will encounter this bug. My best guess is still that this bug is caused by the invisible browser that meek uses not shutting down quickly enough (or at all) during restart of the main browser.
I found an easy way to reproduce this problem.
- Press Shift+F2 to open the Developer Toolbar.
- Type "restart". So this problem doesn't have to do with an update or an add-on per se, but with the restart function that is different from "New Identity" and different from closing the browser and opening it again.
Replying to mcs:
My best guess is still that this bug is caused by the invisible browser that meek uses not shutting down quickly enough (or at all) during restart of the main browser.
I checked and everything is getting new PIDs after restart, everything from the main firefox on down.
If I add an artificial delay to meek-client-torbrowser (
time.Sleep(50*time.Second)) before the call to runFirefox, the error occurs as always, after waiting for 50 seconds. Here is the mysterious part: If I manually run the meek-http-helper profile during those 50 seconds, the headless browser and extension runs and produces output with no problems!$ ./firefox -no-remote -profile Browser/TorBrowser/Data/Browser/profile.meek-http-helper meek-http-helper: listen 127.0.0.1:42056But then as soon as the 50 seconds elapse, the firefox that is started by meek-client-torbrowser fails with the profile error. Even while the profile error is being shown, I can run the headless browser manually with no problem.
I wish I knew how to trace the code path that leads to the "profile cannot be loaded" error, to know what is going wrong in Firefox's opinion.
-
Kathy and I poked at this a little more and we think we found the root cause: before restarting, Firefox sets some environment variables to tell it things like where the profile is, and those are inherited by the meek helper firefox process. If you examine the environment of the meek firefox, you will see things like:
XRE_PROFILE_LOCAL_PATH=/Users/.../tb45.app/TorBrowser/Data/Browser/Caches/profile.default XRE_PROFILE_PATH=/Users/.../tb45.app/TorBrowser/Data/Browser/profile.default etc.On Mac OS, we added this hack to the tor script to test this theory:
unset NO_EM_RESTART XRE_BINARY_PATH XRE_PROFILE_LOCAL_PATH XRE_PROFILE_NAME XRE_PROFILE_PATH X RE_START_OFFLINE XUL_APP_FILEIndeed, the meek restart problem went away.
Now we just need to decide where to place a proper fix. Maybe inside meek-client-torbrowser? The list of env vars to clear may be found here: http://mxr.mozilla.org/mozilla-esr38/source/toolkit/xre/nsAppRunner.cpp#4150
It seems to come down to environment variables that Firefox sets when restarting. Specifically, XRE_PROFILE_PATH, which overrides the -profile option that meek-client-torbrowser uses. If I make this patch, then everything works with no profile error:
--- a/meek-client-torbrowser/meek-client-torbrowser.go +++ b/meek-client-torbrowser/meek-client-torbrowser.go @@ -146,6 +146,7 @@ func main() { log.SetOutput(f) } + os.Unsetenv("XRE_PROFILE_PATH") sigChan := make(chan os.Signal, 1) signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)I compared the environment that meek-client-torbrowser gets when started and restarted. The only difference is some added variables, which are:
+MOZ_APP_RESTART=1 +NO_EM_RESTART= +TZ=UTC +XRE_BINARY_PATH= +XRE_PROFILE_LOCAL_PATH=/home/david/bug13247/tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default +XRE_PROFILE_NAME= +XRE_PROFILE_PATH=/home/david/bug13247/tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default +XRE_START_OFFLINE= +XUL_APP_FILE=Notice that XRE_PROFILE_LOCAL_PATH and XRE_PROFILE_PATH point to profile.default, not profile.meek-http-helper. Firefox seems to prioritize XRE_PROFILE_PATH (didn't test XRE_PROFILE_LOCAL_PATH) over the -profile option on the command line. The profile error we've been seeing is actually caused by the headless browser trying to run the default profile, instead of the meek-http-helper profile asked for on the command line.
I can reproduce the profile error dialog now, using the meek-client-torbrowser delay from comment:16. This command raises the error if executed while Tor Browser is running (even if that Tor Browser is not running meek).
XRE_PROFILE_PATH=/home/david/bug13247/tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default ./firefox -no-remote -profile TorBrowser/Data/Browser/profile.meek-http-helperIf you run the above command when Tor Browser is not running, then it starts a new Tor Browser instance with Tor Launcher and everything, so it's clear the problem is XRE_PROFILE_PATH overriding the -profile option.
So do we just want to apply the Unsetenv patch to meek-client-torbrowser? It seems to suffice.
Trac:
Status: new to needs_review-
Replying to dcf:
So do we just want to apply the Unsetenv patch to meek-client-torbrowser? It seems to suffice.
Wow, that was weird: parallel debugging, and we came to the same conclusion. I say "Yes, let's just clear the env vars." I think it would be safe to clear all of them, but as the meek maintainer that is your call.
Replying to mcs:
Replying to dcf:
So do we just want to apply the Unsetenv patch to meek-client-torbrowser? It seems to suffice.
Wow, that was weird: parallel debugging, and we came to the same conclusion. I say "Yes, let's just clear the env vars." I think it would be safe to clear all of them, but as the meek maintainer that is your call.
Yes, great, thanks for your help :) Instant consensus. Here is the commit I just pushed: https://gitweb.torproject.org/pluggable-transports/meek.git/commit/?id=8cd16980da0cd50e5b6e203a4ee5eaa87725184a It is tag 0.20. I didn't try a complete Tor Browser build, but it worked when I copied the so-built meek-client-torbrowser into a 4.5.2 package.
mentioned in issue #13301 (moved)
mentioned in issue #16014 (moved)
mentioned in issue #16281 (moved)
