Opened 6 months ago

Last modified 4 weeks ago

#30169 new task

Create repos on our infrastructure for TOPL related code

Reported by: gk Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-mobile, tbb-8.5, TorBrowserTeam201905
Cc: igt0, sisbell, sysrqb, hans@…, n8fr8 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We should, now after merging and deploying Tor Onion Proxy Library code (see #27609 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.

Child Tickets

TicketStatusOwnerSummaryComponent
#30337closedtor-gitadmCreate a tor-android-service repositoryInternal Services/Service - git
#30338closedtor-gitadmCreate a tor-onion-proxy-library repositoryInternal Services/Service - git

Change History (13)

comment:1 Changed 6 months ago by gk

Keywords: tbb-8.5 added; tbb-8.5-must removed

We can easily start building even though the repo creation is not done (and we don't use the new repos in our tor-browser-build projects).

comment:2 Changed 6 months ago by gk

I set up the tor-android-service repo with master pointing to the latest commit we ship in tor-browser-build (i.e. 6a9314aff4418a4edac33ff39fae266b097cf000). And I switched to the tpo repo in commit ea0d9948bcb63cce9612f5a6d6e5cdad5db6561c on tor-browser-build's master (+ I cherry-picked that commit onto maint-8.5 (commit 1f5d05032577524ad2600cc2fb7f28cd2d707256)).

Getting master updated follows the usual procedure. We'll have a bug in Trac that needs to get fixed and if that involves fixes in tor-android-service the respective user-owned tor-android-service repo is used for providing the tor-android-service bits (wherever that is, be it on Gitlab or our own infrastructure). Then the whole gets reviewed and the commit in tor-browser-build gets 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).

comment:3 Changed 6 months ago by gk

Keywords: TorBrowserTeam201905 added; TorBrowserTeam201904 removed

Moving tickets to May

comment:4 Changed 4 months ago by gk

Parent ID: #27609

comment:5 Changed 6 weeks ago by 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 TorService integrated into TOPL. I don't think @n8fr8 has plans to integrate TOPL into Orbot. (TorService is the new Android Service that I'm working on for Orbot and tor-android-service).

comment:6 in reply to:  5 Changed 6 weeks ago by sisbell

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 TorService integrated into TOPL. I don't think @n8fr8 has plans to integrate TOPL into Orbot. (TorService is the new Android Service that 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.

comment:7 Changed 6 weeks ago by 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.

comment:8 in reply to:  7 Changed 6 weeks ago by sisbell

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.

https://github.com/thaliproject/Tor_Onion_Proxy_Library/blob/master/universal/src/main/java/com/msopentech/thali/toronionproxy/OnionProxyManager.java

comment:9 Changed 6 weeks ago by sisbell

We'd also need to get back a message from the service as to the control port to connect to.

comment:10 Changed 6 weeks ago by eighthave

How about making the control port be a UNIX domain socket?

comment:11 in reply to:  10 Changed 6 weeks ago by sisbell

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

comment:12 in reply to:  description ; Changed 4 weeks ago by sysrqb

Replying to gk:

We should, now after merging and deploying Tor Onion Proxy Library code (see #27609 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-service repo, however we aren't using the tor-onion-proxy-library yet. We should start doing this and then close this ticket as completed.

comment:13 in reply to:  12 Changed 4 weeks ago by gk

Replying to sysrqb:

Replying to gk:

We should, now after merging and deploying Tor Onion Proxy Library code (see #27609 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-service repo, however we aren't using the tor-onion-proxy-library yet. 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.

Note: See TracTickets for help on using tickets.