#10030 closed defect (fixed)

Tor pluggable transport bundle does not work in OS X Mavericks

Reported by: msfc Owned by:
Priority: normal Milestone:
Component: Tor bundles/installation Version: Tor: 0.2.4.16-rc
Keywords: Cc: mcs, brade
Actual Points: Parent ID:
Points:

Description

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.

Child Tickets

Change History (25)

comment:1 Changed 21 months ago by msfc

  • Summary changed from Tor 2.3.25-13 does not work in OS X Mavericks to Tor does not work in OS X Mavericks

comment:2 Changed 21 months ago by 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?

comment:3 Changed 21 months ago by msfc

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

comment:4 Changed 21 months ago by msfc

  • Summary changed from Tor does not work in OS X Mavericks to Tor pluggable transport bundle does not work in OS X Mavericks

comment:5 follow-ups: Changed 21 months ago by 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.

comment:6 Changed 21 months ago by arma

  • Component changed from Vidalia to Tor bundles/installation
  • Owner chiiph deleted
  • Status changed from new to assigned

comment:7 Changed 21 months ago by arma

  • Priority changed from blocker to normal
  • Status changed from assigned to new

comment:8 in reply to: ↑ 5 ; follow-up: Changed 21 months ago by 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".

comment:9 in reply to: ↑ 8 Changed 21 months ago by 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

Last edited 21 months ago by aze (previous) (diff)

comment:10 in reply to: ↑ 5 Changed 21 months ago by 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.

comment:12 Changed 21 months ago by 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

comment:13 Changed 21 months ago by 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

comment:14 follow-up: Changed 21 months ago by 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)

Last edited 21 months ago by aze (previous) (diff)

comment:15 in reply to: ↑ 14 Changed 21 months ago by 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:

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.

comment:17 Changed 21 months ago by 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

comment:18 Changed 21 months ago by 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.

comment:19 Changed 21 months ago by mcs

  • Cc mcs brade added

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

  • Status changed from new to needs_review

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.

comment:21 Changed 21 months ago by 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.

Last edited 21 months ago by dcf (previous) (diff)

comment:22 follow-up: Changed 21 months ago by dcf

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

comment:23 in reply to: ↑ 22 Changed 21 months ago by ndo23

Replying to dcf:

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

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

comment:24 in reply to: ↑ 20 Changed 21 months ago by 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 "$@"

comment:25 Changed 21 months ago by dcf

  • Resolution set to fixed
  • Status changed from needs_review to closed

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.

Note: See TracTickets for help on using tickets.