Opened 4 years ago
Closed 4 years ago
#10030 closed defect (fixed)
Tor pluggable transport bundle does not work in OS X Mavericks
Reported by: | msfc | Owned by: | |
---|---|---|---|
Priority: | Medium | Milestone: | |
Component: | Applications/Tor bundles/installation | Version: | Tor: 0.2.4.16-rc |
Severity: | Keywords: | ||
Cc: | mcs, brade | Actual Points: | |
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
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 4 years ago by
Summary: | Tor 2.3.25-13 does not work in OS X Mavericks → Tor does not work in OS X Mavericks |
---|
comment:2 Changed 4 years ago by
comment:3 Changed 4 years ago by
Hmmm? The normal bundle is working today. Still have the same issue with pluggable transports. I'll modify the subject.
comment:4 Changed 4 years ago by
Summary: | Tor does not work in OS X Mavericks → Tor pluggable transport bundle does not work in OS X Mavericks |
---|
comment:5 follow-ups: 8 10 Changed 4 years ago by
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 4 years ago by
Component: | Vidalia → Tor bundles/installation |
---|---|
Owner: | chiiph deleted |
Status: | new → assigned |
comment:7 Changed 4 years ago by
Priority: | blocker → normal |
---|---|
Status: | assigned → new |
comment:8 follow-up: 9 Changed 4 years ago by
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 Changed 4 years ago by
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
comment:10 Changed 4 years ago by
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:11 Changed 4 years ago by
Note to self: Related to this: https://lists.torproject.org/pipermail/tor-relays/2013-November/003211.html
comment:12 Changed 4 years ago by
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 4 years ago by
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: 15 Changed 4 years ago by
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)
comment:15 Changed 4 years ago by
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.
comment:16 Changed 4 years ago by
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).
comment:17 Changed 4 years ago by
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 4 years ago by
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 4 years ago by
Cc: | mcs brade added |
---|
comment:20 follow-up: 24 Changed 4 years ago by
Status: | new → 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 4 years ago by
comment:22 follow-up: 23 Changed 4 years ago by
Here are bundles implementing the workaround from comment:20. They work for me.
comment:23 Changed 4 years ago by
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 Changed 4 years ago by
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
totor.real
and then create a shell scripttor
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 4 years ago by
Resolution: | → fixed |
---|---|
Status: | needs_review → 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.
"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?