#32476: Support Launching TorService Using JNI -------------------------------------------------+------------------------- Reporter: sisbell | Owner: tbb- | team Type: defect | Status: new Priority: Medium | Milestone: Component: Applications/Tor Browser | Version: Severity: Normal | Resolution: Keywords: Android, tbb-mobile, | Actual Points: TorBrowserTeam201911 | Parent ID: | Points: Reviewer: | Sponsor: -------------------------------------------------+-------------------------
Comment (by eighthave): > Are the native methods only supported on Android or all platforms? I'm asking this since TOPL is desktop/mobile so this good info to have for planning whether we can continue support across the board. The JNI code should work on any Java or Android version. I tested them on Java only in the beginning, so I don't know the status there. But any breakage there is most likely trivial. Is Desktop TBB using TOPL? > 1) I still see that we need to wait for the control port creation file. This is what was causing some earlier problems. Will this be fixed with the JNI code in the future or does the problem lie in the tor code itself? The best solution for this is to create a pipe/stdin/stdout interface for the ControlPort. Then Java code can interact directly with it, without any kind of socket. This current solution should be better than before because it is based on a UNIX domain socket rather than a TCP socket. So it uses the Linux inotify API, which is quite reliable, to get an event when the socket file is created. > 2) Authentication appears to just be default, with no cookies. If we add cookie base auth, I think we would also need to wait for that file creation as well. > > I bring up (1) and (2) specifically since these were pain points in the past and don't seem to be mitigated in the current code. With a pipe/stdin/stdout interface for the ControlPort, cookie auth is not needed. On Android, creating the UNIX socket file within the app's private file dirs should eliminate the need for the cookie auth, based on standard Android file permissions. Setting the permissions on the socket file itself further ensures that. I have the cookie auth working as well, with an inotify wait, if that's needed. But that'll likely be more brittle, given more moving parts. The change here is switching from TCP socket to UNIX domain socket on the filesystem. That will eliminate a lot of pain points: * no more TCP port conflicts * access control via standard Android file/dir permissions * detect controlport creation using Linux inotify > 3) The JNI code will lock down the implementation class as TorService, which is also the Android service class. I think it would be better to move the JNI interaction to a different class, which is then called by TorService class. This will make it more reusable by third-parties. There is nothing about ''src/feature/api/org_torproject_jni_TorService.c'' that locks it to Android. JNI files do not normally declare a Java class, they implement methods for a class declared in a ''.java'' file. ''tor- android-binary/src/main/java/org/torproject/jni/TorService.java'' is the Android setup. There should be a separate ''TorService.java'' for Java. There isn't enough in the ''TorService.java'' that is shareable between Android and Java. Trying to make a shared super class will make the code really confusing and hard to follow, while only sharing some trivial bits of code. > 4) We are using file descriptor for the control port with the JNI version. This is good. (It does mean this only support *nix based systems). The UNIX domain socket code in `Java_org_torproject_jni_TorService_prepareFileDescriptor()` might only be relevant on Android, but it probably works on Java. I think there are probably better ways to do this on Java. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32476#comment:5> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs