TorBrowser.app.meek-http-helper symlinks incompatible with Gatekeeper signing

Experimentation shows that the symlink approach that we currently use to create a meek-specific "copy" of Tor Browser on Mac OS is not compatible with Apple's Gatekeeper code signing. Apple's codesign command complains about an invalid Info.plist because it is checking that the application binary (firefox) is where the Info.plist says it is and symlinks are apparently not traversed.

One possible solution is to eliminate the TorBrowser.app.meek-http-helper linked app bundle and add support to firefox for a command line option that causes the application to run as a background app. See https://trac.torproject.org/projects/tor/ticket/11429#comment:8 for more info.

Perhaps if we make the call to TransformProcessType() very early during firefox startup the problem that occurred before (dock icon appearing briefly during startup of the meek browser) will not occur. Another possibility is to change the Info.plist for Tor Browser so that the dock icon is hidden by default and then un-hide it when not running as the meek helper browser.

added TorBrowserTeam201603R component::applications/tor browser owner::mcs parent::13252 priority::medium resolution::fixed severity::normal sponsor:: status::closed type::defect labels

Trac:

Brief "nudge" of other dock icons when turning off the browser icon early during startup

Kathy and I did some experimentation yesterday. If we make a call to TransformProcessType() early during the startup process to hide the dock icon, the icon never appears in the dock but the animation to make room for it does begin. Here is what it looks like (notice how the Safari icon is briefly nudged to the left): Since this is fairly subtle, and I think we can live with this (but other people may disagree). The other problem is that the TransformProcessType() call does not work on Mac OS 10.6, so users will see two dock icons on 10.6.

On the other hand, if we switch the main browser plist to have LSBackgroundOnly=true and then make a TransformProcessType() call to show the icon, it works OK but there is no "bounce" animation at all for the main Tor Browser's dock icon. This seems like a worse solution to Kathy and me because it makes the behavior of Tor Browser during launch different from every other Mac application.

Also, for the record (and so other people don't waste their time), we also tried to use [NSApp setActivationPolicy:] as described here: https://stackoverflow.com/questions/5382932/#5384319 It seems to behave exactly like TransformProcessType() (subtle nudge of the other dock icons during startup of the meek helper browser and it does not work at all on Mac OS 10.6).

Trac:
Cc: brade, dcf to brade, dcf, gk

Replying to mcs:

Kathy and I did some experimentation yesterday. If we make a call to TransformProcessType() early during the startup process to hide the dock icon, the icon never appears in the dock but the animation to make room for it does begin. Here is what it looks like (notice how the Safari icon is briefly nudged to the left):

Since this is fairly subtle, and I think we can live with this (but other people may disagree). The other problem is that the TransformProcessType() call does not work on Mac OS 10.6, so users will see two dock icons on 10.6.

Yeah, it doesn't look too bad. I think we can live with it.

For visual comparison, here's how it looked when I tried TransformProcessType in #11429 (moved). It might have been OS X 10.7?

Support for --invisible inside Tor Browser will be included in our forthcoming patches for #13252 (moved).

dcf: Could you review patch + merge it and tag a new release in case you are satisfied with it? This is currently blocking the OS X signing we want to test in the alphas.

Trac:
Status: new to needs_review

Here are a few minor revisions I'd like to see:

• Copy the profile to a temporary directory (ioutil.TempDir) and rename it atomically (os.Rename). Otherwise, the copy could fail halfway through but the os.Stat check in ensureProfileExists will be fooled.
• Use filepath.Join to join path instead of string concatenation.
• In copyFile, you can use os.OpenFile to avoid a separate call to os.Chmod.

How do you want the tags to work? I'm assuming that a meek-client-torbrowser using this patch will only work in an alpha TB, not in a stable. So I'm thinking of making it a parallel branch, rather than extending master. (Maybe this is an argument for moving the meek-client-torbrowser code into the tor-browser-bundle repo.)

Trac:
Status: needs_review to needs_revision

Replying to dcf:

Here are a few minor revisions I'd like to see:

• Copy the profile to a temporary directory (ioutil.TempDir) and rename it atomically (os.Rename). Otherwise, the copy could fail halfway through but the os.Stat check in ensureProfileExists will be fooled.
• Use filepath.Join to join path instead of string concatenation.
• In copyFile, you can use os.OpenFile to avoid a separate call to os.Chmod.

We made those changes. I will attach a revised patch.

How do you want the tags to work? I'm assuming that a meek-client-torbrowser using this patch will only work in an alpha TB, not in a stable. So I'm thinking of making it a parallel branch, rather than extending master. (Maybe this is an argument for moving the meek-client-torbrowser code into the tor-browser-bundle repo.)

I will leave the branch decision to Georg, but yes, this is is an alpha-only thing for now.

Trac:
0001-Bug-18371-symlinks-incompatible-with-Gatekeeper-sign.patch

revised patch

Trac:
Status: needs_revision to needs_review
Keywords: N/A deleted, TorBrowserTeam201603R added

Replying to dcf:

How do you want the tags to work? I'm assuming that a meek-client-torbrowser using this patch will only work in an alpha TB, not in a stable. So I'm thinking of making it a parallel branch, rather than extending master. (Maybe this is an argument for moving the meek-client-torbrowser code into the tor-browser-bundle repo.)

I have no strong opinions here although I am not so sure about moving meek-clienr-torbrowser into the tor-browser-bundle repo. Giving that the modifications should be for stable users as well once we switch to ESR 45 (which is basically due end of May) a new branch we would use for now might be okay?

Looks good. I made you a branch bug18371 with a signed tag 0.22-18371-1.

meek does not work with the patch on my OS X 10.6 test machine:

2016/03/09 12:34:20 creating profile by copying files from ../../Resources/TorBrowser/Tor/PluggableTransports/template-profile.meek-http-helper to /Users/release/Desktop/TorBrowser-Data/Tor/PluggableTransports/profile.meek-http-helper
2016/03/09 12:34:20 mkdir /Users/release/Desktop/TorBrowser-Data/Tor/PluggableTransports/tmpMeekProfile667155114: no such file or directory

Trac:
Status: needs_review to needs_revision

Trac:
Keywords: TorBrowserTeam201603R deleted, TorBrowserTeam201603 added

Trac:
0001-fixup-Bug-18371-symlinks-incompatible-with-Gatekeepe.patch

fixup patch

Replying to gk:

meek does not work with the patch on my OS X 10.6 test machine: ...

Sorry about that! After Kathy and I made the changes suggested by dcf we did not do a clean test. I attached a fixup patch.

Trac:
Status: needs_revision to needs_review
Keywords: TorBrowserTeam201603 deleted, TorBrowserTeam201603R added
Reviewer: N/A to N/A