Tor pluggable transport bundle does not work in OS X Mavericks

[msfc]

When I attempt to run the TorBrowser bundle 2.3.25-13 or TorBrowser pluggable transports 2.4.16-beta-1 on OS X 10.9 Mavericks Vidalia gets as far as "Connecting to a relay directory" and makes no further progress.

When I look at the Advanced logs I see messages that it "could not launch managed proxy executable at flashproxy-client". Same for obfsproxy.bin. The reason given for both is 'No such file or directory.'

The files, of course still exist in the package in the same folder as Vidaia and TorBrowser.

[dcf]

"could not launch managed proxy executable at flashproxy-client" is a message that only the pluggable transports bundle can output. What log messages do you get in the normal bundle?

[msfc]

Hmmm? The normal bundle is working today. Still have the same issue with pluggable transports. I'll modify the subject.

[dcf]

Could you try editing the torrc file as described here?

https://trac.torproject.org/projects/tor/wiki/FlashProxyHowto#Findingtorrc

I want you to change these two lines:

ClientTransportPlugin flashproxy exec flashproxy-client --register :0 :9000
ClientTransportPlugin obfs2,obfs3 exec obfsproxy.bin managed

to this:

ClientTransportPlugin flashproxy exec ./flashproxy-client --register :0 :9000
ClientTransportPlugin obfs2,obfs3 exec ./obfsproxy.bin managed

That is, just add ./ in front of both executable names.

[msfc]

Replying to dcf:

That is, just add ./ in front of both executable names.

It still doesn't work. The only difference is that the error messages now say, e.g., "executable at ./flashproxy-client".

[aze]

Replying to msfc:

Replying to dcf:

That is, just add ./ in front of both executable names.

It still doesn't work. The only difference is that the error messages now say, e.g., "executable at ./flashproxy-client".

If TorBrowser is moved to /Applications folder, edit torrc to

ClientTransportPlugin websocket exec /Applications/TorBrowser_en-US.app/Contents/MacOS/flashproxy-client --register :0 :9000
ClientTransportPlugin obfs2,obfs3 exec /Applications/TorBrowser_en-US.app/Contents/MacOS/obfsproxy.bin managed

ps : torbrowser shouldn't be open in another folder before that as it edit torrc at first launch, so just after unzipping tor pluggable transport bundle move TorBrowser_en-US to /Applications and then edit torrc

[gmorehouse]

That is, just add ./ in front of both executable names.

For anybody surfing in in the future, an absolute path would be better than './'

Change to the directory where your flashproxy-client and your obfsproxy.bin are located (both, if different for any reason), run 'pwd' and put the full path in.

[asn]

Note to self: Related to this: ​https://lists.torproject.org/pipermail/tor-relays/2013-November/003211.html

[dcf]

I haven't been able to test this bug on an actual installation of Mavericks.

Using ./ doesn't appear to work. Setting an absolute path is a good workaround, but going forward we need to figure out what the actual relative path should be.

asn: my guess is that somehow either Tor's working directory or the default PATH within app bundles has changed in Mavericks.

Maybe someone could try this? It won't make your bundle run, but it will give us information we need to solve the problem. Create a file /tmp/pathtest.sh with the contents:

#!/bin/sh
pwd >> /tmp/pathtest.txt
echo $PATH >> /tmp/pathtest.txt

Make it executable:

chmod +x /tmp/pathtest.sh

Add a line to torrc:

ClientTransportPlugin pathtest exec /tmp/pathtest.sh

Then double-click to run the bundle. The "pathtest" transport will of course fail, but it will create a file /tmp/pathtest.txt containing the information that I think will help us. If the information contains your username or anything like that, you can feel free to obscure it.

Here is what /tmp/pathtest.txt looks like for me on OS X 10.8:

/Users/david/bundle/TorBrowser_en-US.app/Contents/MacOS
/usr/bin:/bin:/usr/sbin:/sbin:/usr/sbin

[asn]

I asked a friendly guy in #tor to follow comment:12.

Here is his /tmp/pathtest.txt:

/
/usr/bin:/bin:/usr/sbin:/sbin:/usr/sbin

[aze]

On 10.9 Mavericks

cat /tmp/pathtest.txt
/
/usr/bin:/bin:/usr/sbin:/sbin:/usr/sbin

and here's a warning in console.app when i launch TorBrwoser_en-US.app

04/11/2013 13:19:32,232 syspolicyd[7512]: assessment denied for .app but overridden
com.apple.message.domain: com.apple.security.assessment.outcome2
com.apple.message.signature2: bundle:org.torproject.TorBrowserBundle
com.apple.message.signature3: .app
com.apple.message.signature5: 2.4.16-beta-1
com.apple.message.signature4: 1
com.apple.message.signature: defeated:no usable signature
Sender_Mach_UUID: BC330C6C-****-****-****-B751D5317E0D

it can be reproduce anytime i launch it
(i've added stars in uuid)

[dcf]

Replying to aze:

On 10.9 Mavericks

cat /tmp/pathtest.txt
/
/usr/bin:/bin:/usr/sbin:/sbin:/usr/sbin

Thanks. It looks like this change in working directory is the direct cause of the problem.

Somehow the app bundle manages to launch Vidalia and Vidalia manages to launch Tor. But Tor isn't able to launch its pluggable transports. We should find out what Vidalia or other startup script is doing differently that makes it work.

I found reports in other software that seem to have the same cause:

• ​QDir::currentPath() not returning current application's folder pathname under OSX 10.9 Mavericks
• ​QDir::currentPath() OSX 10.9 Mavericks bug
• ​Mac OS X 10.9: problem with loading program icons

The first link says that QDir::currentPath() returns "/" (or an empty string, it's not clear), while QApplication::applicationDirPath() returns something useful. So we could check out what QApplication::applicationDirPath() does.

[asn]

FWIW, QApplication::applicationDirPath() is here:
​https://qt.gitorious.org/qt/qt/source/cfadf08a6c06ce319f6144e724f45e4923e72778:src/corelib/kernel/qcoreapplication.cpp#L1705

QDir::currentPath() is here:
​https://qt.gitorious.org/qt/qt/source/57756e72adf2081137b97f0e689dd16c770d10b1:src/corelib/io/qdir.cpp#L1760-1763
which (for OSX) seems to be here:
​https://qt.gitorious.org/qt/qt/source/57756e72adf2081137b97f0e689dd16c770d10b1:src/corelib/io/qfsfileengine_unix.cpp#L576-590
(but I might be wrong).

[msfc]

I tried the full path as suggested in comment #9. I get the same failure:

Nov 07 22:36:16.443 [Warning] Could not launch managed proxy executable at '"/Applications/TorBrowser_en-US_PluggableTransports.app/Contents/MacOS/flashproxy-client"' ('No such file or directory').
Nov 07 22:36:16.444 [Warning] Could not launch managed proxy executable at '"/Applications/TorBrowser_en-US_PluggableTransports.app/Contents/MacOS/obfsproxy.bin"' ('No such file or directory').

Yes flashproxy-client and obfsproxy.bin *are* at that location.

ls -l /Applications/TorBrowser_en-US_PluggableTransports.app/Contents/MacOS/flashproxy-client
-rwxr-xr-x 1 xxxxxx staff 46453 Aug 14 18:47 /Applications/TorBrowser_en-US_PluggableTransports.app/Contents/MacOS/flashproxy-client

ls -l /Applications/TorBrowser_en-US_PluggableTransports.app/Contents/MacOS/obfsproxy.bin
-rwxr-xr-x 1 xxxxxx staff 449 Aug 14 18:47 /Applications/TorBrowser_en-US_PluggableTransports.app/Contents/MacOS/obfsproxy.bin

[msfc]

If I remove those " marks from from around the full path vidalia does get beyond "connecting to a relay directory" but then stalls at "loading relay directory", or something like that. The only warning in the log is:

Nov 07 22:50:05.243 [Warning] Proxy Client: unable to connect to 208.79.90.242:55564 ("server rejected connection")

I had the " marks because originally there was a space in the path name.

[dcf]

I found a workaround that we can deploy relatively quickly without having to modify tor.

The problem is that Finder in Mavericks sets the current directory to /, so relative paths to pluggable transport executables don't work. What we can do is move tor to tor.real and then create a shell script tor with something like:

#!/bin/sh
cd $(dirname $0)
exec ./tor.real $@

I tested this idea on Mavericks and it works. What do you say?

Vidalia is using the above mentioned QApplication::applicationDirPath (​see here), which is why it didn't break with the changed behavior in Mavericks.

A more permanent fix may be to have tor do this same thing: either set its current directory or else absolutize the paths to subprograms based on the executable directory.

[dcf]

#10092 and #10135 may be about this same problem, except referring to the geoip file. That would affect the normal bundles too, not just the PT bundles.

[dcf]

Here are bundles implementing the workaround from comment:20. They work for me.

• ​https://people.torproject.org/~dcf/pt-bundle/2.4.17-rc-1-pt2/osx/

[ndo23]

Replying to dcf:

Here are bundles implementing the workaround from comment:20. They work for me.

• ​https://people.torproject.org/~dcf/pt-bundle/2.4.17-rc-1-pt2/osx/

this bundle works on showing the little flags location on the left sides but those not show the actual lines connecting in the map

[dcf]

Replying to dcf:

The problem is that Finder in Mavericks sets the current directory to /, so relative paths to pluggable transport executables don't work. What we can do is move tor to tor.real and then create a shell script tor with something like:

#!/bin/sh
cd $(dirname $0)
exec ./tor.real $@

In ​what I actually committed, I added some quoting so that it will work even when in a directory whose name contains spaces.

#!/bin/sh
cd "$(dirname "$0")"
exec ./tor.real "$@"

[dcf]

​2.4.17-rc-1-pt2 is published with this workaround.

I think something similar is going to be needed in even the vanilla bundles, because the changed working directory appears to prevent the finding of geoip files, as reported in #10092 and #10135.