Opened 2 years ago

Closed 20 months ago

#13247 closed defect (fixed)

meek profile error after browser restarts (e.g., after update or add-on installation)

Reported by: mcs Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: meek, tbb-usability
Cc: brade, dcf Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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:

  1. Configure TB 4.0-alpha-2 with the meek-amazon transport.
  1. 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).
  1. 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.

Child Tickets

Attachments (4)

TB update failure meek.png (187.5 KB) - added by mcs 2 years ago.
"Profile Missing" error alert (Mac OS)
select-addons.png (68.9 KB) - added by mcs 2 years ago.
Select Your Add-ons window (which we do not want users to ever see)
profile-missing-4.0-alpha-3-linux.png (27.1 KB) - added by dcf 2 years ago.
select-addons-4.0-alpha-3-linux.png (45.9 KB) - added by dcf 2 years ago.

Download all attachments as: .zip

Change History (26)

Changed 2 years ago by mcs

"Profile Missing" error alert (Mac OS)

comment:1 follow-up: Changed 2 years ago by 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:

[General]
StartWithLastProfile=1

[Profile0]
Name=default
IsRelative=1
Path=profile.default
Default=1

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".

comment:2 in reply to: ↑ 1 Changed 2 years ago by mcs

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.

Changed 2 years ago by mcs

Select Your Add-ons window (which we do not want users to ever see)

comment:3 Changed 2 years ago by mcs

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:

1) Install a new TB 4.0-alpha-3 browser and configure it to use meek.

2) 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.

3) 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.

comment:4 Changed 2 years ago by dcf

I found this article describing attachment:select-addons.png:

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}}}]");

comment:5 Changed 2 years ago by dcf

Putting images inline so they're easier to see:
"Profile Missing" error alert (Mac OS)
Select Your Add-ons window (which we do not want users to ever see)
I got the same thing today when the updater updated to 4.0-alpha-3:


Changed 2 years ago by dcf

Changed 2 years ago by dcf

comment:6 Changed 2 years ago by mcs

  • Summary changed from meek profile error after update to meek profile error after browser restarts (e.g., after update or add-on installation)

comment:7 Changed 2 years ago by dcf

  • Keywords meek added

comment:8 Changed 2 years ago by mikeperry

  • Keywords TorBrowserTeam201411 added

comment:9 Changed 2 years ago by mikeperry

  • Keywords TorBrowserTeam201412 added; TorBrowserTeam201411 removed

comment:10 Changed 2 years ago by mikeperry

  • Keywords TorBrowserTeam201501 added; TorBrowserTeam201412 removed

comment:11 Changed 2 years ago by mikeperry

  • Keywords TorBrowserTeam201501 removed

This is the PT team's domain more than Tor Browser Team.

comment:12 Changed 2 years ago by dcf

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."

comment:13 follow-up: Changed 22 months ago by mcs

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.

comment:14 Changed 21 months ago by mcs

  • Keywords tbb-usability added

comment:15 Changed 20 months ago by dcf

I found an easy way to reproduce this problem.

  1. Press Shift+F2 to open the Developer Toolbar.
  2. 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.

comment:16 in reply to: ↑ 13 Changed 20 months ago by dcf

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:42056

But 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.

comment:17 Changed 20 months ago by mcs

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_FILE

Indeed, 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

comment:18 follow-up: Changed 20 months ago by dcf

  • Status changed from new to needs_review

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:

  • meek-client-torbrowser/meek-client-torbrowser.go

    a b func main() { 
    146146               log.SetOutput(f)
    147147       }
    148148
     149       os.Unsetenv("XRE_PROFILE_PATH")
    149150       sigChan := make(chan os.Signal, 1)
    150151       signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
    151152

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-helper

If 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.

comment:19 in reply to: ↑ 18 ; follow-up: Changed 20 months ago by 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.

comment:20 in reply to: ↑ 19 Changed 20 months ago by dcf

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.

comment:21 Changed 20 months ago by mcs

We may want to pick this up for TB 5.0a3 so it gets some testing.

comment:22 Changed 20 months ago by gk

  • Resolution set to fixed
  • Status changed from needs_review to closed
Note: See TracTickets for help on using tickets.