Make meek-client-torbrowser take the firefox command as a parameter
meek-client-torbrowser hardcodes the firefox binary and profile paths: linux mac windows. The problem is that when Tor Browser is reorganized, as it was in #11641 (closed), you need to make the corresponding change in meek-client-torbrowser, for example 178572f5.
meek-client-torbrowser already takes the full meek-client command on the command line; it looks like:
ClientTransportPlugin meek exec ./TorBrowser/Tor/PluggableTransports/meek-client-torbrowser -- ./TorBrowser/Tor/PluggableTransports/meek-client --url=https://meek-reflect.appspot.com/ --front=www.google.comI don't know of a good clear way to encode two separate command lines into the command line of another program, except maybe to do them both as long strings and then parse the strings before calling exec.
Activity
0001-Add-firefox-and-profile-options-to-meek-client-torbr.patch adds --firefox and --profile options to meek-client-torbrowser. I'm not sure that's the best way to go. It looks like this:
./meek-client-torbrowser --firefox ./firefox --profile TorBrowser/Data/Browser/profile.meek-http-helper -- ./meek-clientI thought of passing both complete commands as strings, like
./meek-client-torbrowser --firefox "./firefox -no-remote -profile TorBrowser/Data/Browser/profile.meek-http-helper" --meek-client "./meek-client"But then there would need to be code to split up a quoted string, and I'm not sure I want that. Also I think tor might split up a ClientTransportPlugin line on whitespace, and chop up the quoted strings.
Another option is to slightly abuse -- as an additional separator between the firefox command and the meek-client command:
./meek-client-torbrowser -- ./firefox -no-remote -profile TorBrowser/Data/Browser/profile.meek-http-helper -- ./meek-clientYou can get away with that because firefox doesn't use --.
But there's an additional problem with passing a complete firefox command line. Mac OS X needs an absolute path for the profile directory, so meek-client-torbrowser absolutizes it. It couldn't do that easily if the whole command were to come as a unit.
Replying to dcf:
But there's an additional problem with passing a complete firefox command line. Mac OS X needs an absolute path for the profile directory, so meek-client-torbrowser absolutizes it. It couldn't do that easily if the whole command were to come as a unit.
Why does Mac OS need an absolute path to the profile directory? Is that a Firefox limitation? Nevermind. I found this: https://bugzilla.mozilla.org/show_bug.cgi?id=673955
How inconvenient.
Replying to mcs:
Replying to dcf:
But there's an additional problem with passing a complete firefox command line. Mac OS X needs an absolute path for the profile directory, so meek-client-torbrowser absolutizes it. It couldn't do that easily if the whole command were to come as a unit.
Why does Mac OS need an absolute path to the profile directory? Is that a Firefox limitation? Nevermind. I found this: https://bugzilla.mozilla.org/show_bug.cgi?id=673955
Hmm, I see. I wasn't aware of that Mozilla bug. I had assumed the reason was how OS X 10.9 started setting the working directory of applications to "/"; i.e., the same reason we do the silly tor.real trick a.k.a. #10030 (closed). But I could be wrong.
How about the following:
meek-client-helper /path/to/meek/client <meek-client args> -- <helper command line>We know meek-client doesn't use --, so this is safe in all cases. Then, meek-client-helper doesn't need any args of its own.
To make things work on OSX, we do this in the Bridge line (until that Mozilla bug is fixed):
meek-client-helper <etc> -- sh -c 'exec "$1" -no-remote -profile "$(realpath "$2")"' TBB ./rel/path/to/firefox ./rel/path/to/profile"TBB" can be anything, it's just what would show up in process lists as the "command name".
This means we can remove all firefox/tbb specificness from this program, as well as the OSX workaround. I am hoping the Bridge line supports args with spaces in. If it doesn't, we can instead write a wrapper shell script that calls firefox and does $(realpath) on the profile arg.
I'm not in love with any idea that has been proposed so far. The double-dash idea from comment:1 and comment:5 is workable, but I think we would grow to dislike it.
The
sh -c exec "$1"idea in comment:5 is about 1.2× as crazy I usually like solutions to be :) But it's headed in a good direction. What infinity0 wrote "we can instead write a wrapper shell script that calls firefox" is what we should do, I think.Here's what I'm thinking:
meek-client-helper --helper ./path/to/helper.sh -- ./path/to/meek-clientThe --helper option is the program that runs the helper. However the catch is that you only get to specify the name of a single file to run: no arguments, no shell expansion, and no string splitting. Anything that the helper needs, for example the path to the profile, or a call to realpath, has to be encoded into the script.
In the browser bundle, we'll have a different helper script for each OS, corresponding to the current linux.go, mac.go, and windows.go in meek-client-torbrowser. On windows we can use, I don't know, a batch file or something, or in the worst case yet another compiled program. The customization for Debian will be just one Debian-specific shell script.
The reason for having a --helper option instead of having it being implied by position is to leave room for other options in meek-client-helper like --log. It keeps the usual meaning of --; i.e., everything before -- "belongs" to meek-client-helper and everything after is a non-option. Omitting the --helper option could mean to just run meek-client directly without a helper (which is sometimes useful).
Here's a first attempt at doing as suggested in David's previous comment:
Replying to infinity0:
Here's a first attempt at doing as suggested in David's previous comment:
I took a quick look and it looks like what I expected. Thanks.
Two questions:
- Does this work for what Debian/Tails/Whonix wants?
- What is the meek-browser-helper script for? My first instinct is not to add new functionality (auto-installing a profile).
meek-browser-helper is similar in functionality to tbb-linux.sh, except it also automatically creates a user profile with that extension enabled. That is, you can use it like
ClientTransportPlugin meek exec meek-client-wrapper --helper meek-browser-helper -- meek-client <args>etc. It's meant to work on a clean linux system where you don't already have a pre-made profile for meek-http-helper (unlike TBB).I'm planning to have it in the Debian package, but it should be generic enough to work for other Linux distros as well (the hardcoded paths are same across linux distros) - which is why I didn't add a -debian suffix to the filename.
Trac:
12716-1.patch.gzHere is a build of Tor Browser that uses the branch from comment:7. https://people.torproject.org/~dcf/pt-bundle/4.5a4-12716-1/ It's built using this patch to tor-browser-bundle: 12716-1.patch.gz I tested it on linux64 but not any other platforms. I asked tor-qa for testing here: https://lists.torproject.org/pipermail/tor-qa/2015-March/000555.html
Replying to dcf:
I tested it on linux64 but not any other platforms. I asked tor-qa for testing here: https://lists.torproject.org/pipermail/tor-qa/2015-March/000555.html
Wilton and Mark say it doesn't work on OS X, giving an error "Your Firefox profile cannot be loaded." Mark suggests it's because there is no realpath on OS X.
Here is the meek-browser-helper-mac.sh script:
# Mac OS X needs an absolute profile path. # https://bugzilla.mozilla.org/show_bug.cgi?id=673955 exec "PluggableTransports/TorBrowser.app.meek-http-helper/Contents/MacOS/firefox" \ -no-remote -profile "$(realpath "../Data/Browser/profile.meek-http-helper")"Maybe it could use dirname like mac-tor.sh does?
Oh! infinity0, please do not add a default browser helper argument like this. I'm fine with having the meek-browser-helper script in the repo as an example, but I do not want to make it the default behavior for everybody. I was surprised when I ran it and got this error:
2015/03/13 09:22:17 running browser-helper command ["meek-browser-helper"] 2015/03/13 09:22:17 exec: "meek-browser-helper": executable file not found in $PATHI want this to be a place where distributions set policy, not us.
Trac:
Status: new to needs_revisionreadlink -fshould work instead ofrealpath. I've asked tor-qa about this.The Go options library does not allow "required options" because they are an oxymoron - they recommend that required options should instead be a positional argument - https://groups.google.com/forum/#!topic/golang-nuts/agYvRPNaBNA
So I thought a default value of "meek-browser-helper" was the best option - it would work at least some of the time (as opposed to none of the time), and distros can still install their own /usr/bin/meek-browser-helper if they disagreed with the example script given.
An alternative is to set the default value to "", and if this is not set by the user then give a custom error message like "either set --helper or use meek-client directly". Will do that in a commit tomorrow if you prefer.
Replying to infinity0:
readlink -fshould work instead ofrealpath. I've asked tor-qa about this.$(dirname "$0")might work. You don't need a canonical path, just an absolute path.The Go options library does not allow "required options" because they are an oxymoron - they recommend that required options should instead be a positional argument - https://groups.google.com/forum/#!topic/golang-nuts/agYvRPNaBNA
So I thought a default value of "meek-browser-helper" was the best option - it would work at least some of the time (as opposed to none of the time), and distros can still install their own /usr/bin/meek-browser-helper if they disagreed with the example script given.
An alternative is to set the default value to "", and if this is not set by the user then give a custom error message like "either set --helper or use meek-client directly". Will do that in a commit tomorrow if you prefer.
The last one is what I had in mind—just output an error. Or we could just make it really optional, and not run any helper (nor pass --helper to meek-client) if it's missing.