Create repos on our infrastructure for TOPL related code
We should, now after merging and deploying Tor Onion Proxy Library code (see #27609 (moved) and child tickets), get the code onto into our tpo git infrastructure, I think, and create additional user repositories if needed.
So, having some tor-onion-proxy-library repo we use (and for which the github one could be the official upstream) and one for tor-android-service where we can tag and sign releases would be a good start. Not sure if there is more we should consider.
Then we can get changes to any of the new projects treated with our normal code review and commit push process.
We should think about who should have push access to those repos. I think sisbell, sysrqb, and I could be a decent start for that.
Activity
Trac:
Child Ticket(s): #30337 (moved), #30338 (moved)
I set up the
tor-android-servicerepo withmasterpointing to the latest commit we ship intor-browser-build(i.e. 6a9314aff4418a4edac33ff39fae266b097cf000). And I switched to the tpo repo in commit ea0d9948bcb63cce9612f5a6d6e5cdad5db6561c ontor-browser-build'smaster(+ I cherry-picked that commit ontomaint-8.5(commit 1f5d05032577524ad2600cc2fb7f28cd2d707256)).Getting
masterupdated follows the usual procedure. We'll have a bug in Trac that needs to get fixed and if that involves fixes intor-android-servicethe respective user-ownedtor-android-servicerepo is used for providing thetor-android-servicebits (wherever that is, be it on Gitlab or our own infrastructure). Then the whole gets reviewed and the commit intor-browser-buildgets updated if everything looks good. The ticket then gets closed.At some point we should think about tagging releases + sign them and use git tags for our
maint-*branches (will say stable releases).-
Trac:
Parent: #27609 (moved) to N/A 
Is TOPL used in Tor Browser at all? Or is the idea to make official Tor releases of TOPL? I'm wondering how much effort I should put into getting this new
TorServiceintegrated into TOPL. I don't think @n8fr8 has plans to integrate TOPL into Orbot. (TorServiceis the new AndroidServicethat I'm working on for Orbot and tor-android-service).Replying to eighthave:
Is TOPL used in Tor Browser at all? Or is the idea to make official Tor releases of TOPL? I'm wondering how much effort I should put into getting this new
TorServiceintegrated into TOPL. I don't think @n8fr8 has plans to integrate TOPL into Orbot. (TorServiceis the new AndroidServicethat I'm working on for Orbot and tor-android-service).tor-android-service uses TOPL so yes its included in the Android version of Tor Browser, not the desktop version. TOPL contains code that is common to desktop (JAVA) and Android, with abstractions that can be extended for each platform.
I'm unsure on what the scope of the TorService you are working on. Is it bootstrap of tor? Installation? Configuration of torrc? Does it include tor control connection management?
There is not a strict requirement to use TOPL for Android. TOPL does contain a fair amount of code that an Android service needs to use and manage tor. So I guess it depends on the scope of TorService as to what it can replace.
-
Tthe basic idea is to make an Android-native TorService, which is a subclass of android.app.Service and loads tor daemon as a shared library, and starts it via JNI methods. This should be pretty close to how iOS apps use tor. Then that TorService should then plug into Orbot, Tor Browser, Briar, etc. Then based on that, I'll make a standalone, dead simple "TorServices" app that only provides Tor. No PTs, HSs, etc., just a tor daemon linked in as a shared library, providing a SOCKS and HTTP CONNECT proxy via tor. So I won't really be working on the control port stuff at all.
Then I'll be working on the apps choosing which tor provider to use, since we'll have a new TorServices, super minimal app, so apps that don't include Tor will have to figure out how to use Orbot and/or TorServices. Then that work will hopefully be extended into sharing tor between apps, e.g. letting Briar, Tor Browser, etc share the tor SOCKS proxy to other apps that want to use it. That would happen via Android mechanisms like Intents to manage the discovery of SOCKS ports.
Replying to eighthave:
Tthe basic idea is to make an Android-native TorService, which is a subclass of android.app.Service and loads tor daemon as a shared library, and starts it via JNI methods. This should be pretty close to how iOS apps use tor. Then that TorService should then plug into Orbot, Tor Browser, Briar, etc. Then based on that, I'll make a standalone, dead simple "TorServices" app that only provides Tor. No PTs, HSs, etc., just a tor daemon linked in as a shared library, providing a SOCKS and HTTP CONNECT proxy via tor. So I won't really be working on the control port stuff at all.
Then I'll be working on the apps choosing which tor provider to use, since we'll have a new TorServices, super minimal app, so apps that don't include Tor will have to figure out how to use Orbot and/or TorServices. Then that work will hopefully be extended into sharing tor between apps, e.g. letting Briar, Tor Browser, etc share the tor SOCKS proxy to other apps that want to use it. That would happen via Android mechanisms like Intents to manage the discovery of SOCKS ports.
Thanks. This makes it clearer. Some basic ideas for discussion and further consideration: I think the method that a TorService replaces is the
OnionProxyManager.start method. This method takes three steps. It spawns tor, it waits for the control connection to start up and then it sends some tor control commands. TorService would replace these first two steps (from my understanding).
OnionProxyManager.spawnTorProcess method (currently private). This basically starts up tor from the command line.
OnionProxyManager.waitForControlPortFileCreation would be the other potential method that TorService replaces, since I assume that that will be part of the bootstrap.
We can make the OnionProxyManager.start method abstract, with different implementations for desktop and for Android. I'm sure there is more that would going on here since TorService is an AndroidService, with commands and/or broadcast it needs to receive. But that's the basic idea.
Replying to eighthave:
How about making the control port be a UNIX domain socket?
That's also a good idea, its more secure. There is an issue tracking it in TOPL but no current movement on it
https://github.com/thaliproject/Tor_Onion_Proxy_Library/issues/101
Replying to gk:
We should, now after merging and deploying Tor Onion Proxy Library code (see #27609 (moved) and child tickets), get the code onto into our tpo git infrastructure, I think, and create additional user repositories if needed.
So, having some tor-onion-proxy-library repo we use (and for which the github one could be the official upstream) and one for tor-android-service where we can tag and sign releases would be a good start. Not sure if there is more we should consider.
We completed part (1) with creating the repos, and we're using the
tor-android-servicerepo, however we aren't using thetor-onion-proxy-libraryyet. We should start doing this and then close this ticket as completed.-
Replying to sysrqb:
Replying to gk:
We should, now after merging and deploying Tor Onion Proxy Library code (see #27609 (moved) and child tickets), get the code onto into our tpo git infrastructure, I think, and create additional user repositories if needed.
So, having some tor-onion-proxy-library repo we use (and for which the github one could be the official upstream) and one for tor-android-service where we can tag and sign releases would be a good start. Not sure if there is more we should consider.
We completed part (1) with creating the repos, and we're using the
tor-android-servicerepo, however we aren't using thetor-onion-proxy-libraryyet. We should start doing this and then close this ticket as completed.I guess we should talk about that after the esr transition when we think about what tools/libraries we want to use in the future.
mentioned in issue #30338 (moved)
mentioned in issue #30337 (moved)