Hi, Michael Gold wrote (29 Aug 2015 16:55:28 GMT) : > It is inappropriate to assume Tor is running on this port, as any local > user could be running a service there (Debian bug #797335), possibly to > interfere with torbrowser-launcher.
Note that torbrowser-launcher Depends: tor, so this is correct if, and only if, the system administrator has disabled the tor service, or configured it to not listen on the default SOCKS port. I agree the current "little-t-tor + Tor using applications" situation is sub-optimal from a security and UX point-of-view, e.g. torsocks and Torbirdy are also impacted (and, transitively, anything that uses torsocks). Now, I don't think that filing bugs against all packages that assume a Tor SOCKS port on 9050 will help much: that's not the place where the root cause of this problem will be addressed, as said packages have no means to guess that the system Tor's configuration has been tweaked. And in the current state of things, that's simply the best they can do (unless perhaps an unprivileged user can learn what UID opened a port locally, and check if it's `debian-tor'?). I see that you've also reported bug #797341, so I'm glad you are also working on solving the core problem :) > torbrowser-launcher should allow the user to select an alternate TCP or > Unix-domain SOCKS address, and shouldn't connect to an unprivileged one > without confirmation. Given 1. the design goals of torbrowser-launcher (that is: working out-of-the-box for non-technical users, AIUI); 2. the current state of things as described above; and 3. the fact that in practice this is a problem only if the system administrator tweaked torrc in a way that ignores #2, I beg to disagree that this would be a good solution to the (real) problem we have here. Now, *if* the quick fix I'm suggesting above works (checking who opened the SOCKs port before connecting to it), then it could be an acceptable temporary fix for users who get torbrowser-launcher from their distro. Cheers, -- intrigeri