[tor-bugs] #32303 [Applications/Tor Browser]: obfs4proxy incompatibility on Android Q
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Nov 26 08:44:56 UTC 2019
#32303: obfs4proxy incompatibility on Android Q
-------------------------------------------------+-------------------------
Reporter: sysrqb | Owner: tbb-
| team
Type: defect | Status: closed
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution: fixed
Keywords: tbb-rbm, tbb-9.0-issues, | Actual Points:
tbb-9.0.1-can, TorBrowserTeam201911R |
Parent ID: | Points: 1
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by gk):
Replying to [comment:26 eighthave]:
> It would be great if Tor built all the binaries! Here's the ideal as I
see it:
>
> * Guardian, Briar, Thali, Tor all move towards common components
(libtor.so, PTs, jtorctl, TorService, etc)
> * Tor Project makes official binaries for all the components used in TBB
> * TBB uses those binary components directly, via the local gradle/maven
cache that's current in use
> * Tor Project also pushes those binary components to Maven Central for
all other consumers to use
> * components not used by TBB will still be released by Guardian, etc.
>
> Between all the projects (Tor, Guardian, Briar, Thali, etc) have all the
pieces of this implementing and working, we just need to rearrange things.
This may seem like just shifting work to Tor Project, but if we do this
right, I don't think it'll add more work for Tor Project, given the TBB
requirements of building all binaries and building them reproducibly.
Making TBB consume these components as binary releases will reduce the TBB
flexibility a bit, but it will mean that all of the testing and
integration work done by Guardian, Briar, Thali, etc. will directly apply
to TBB. I think it will pay off for TBB alone because of that, and it
will also greatly simplify things for the rest.
>
> This can happen now for libtor.so and PT executables, as far as I see
it. jtorctl will need work to integrate all the forks so the various
projects can all use the same jtorctl. Then TorService will be easy to
share once there is a canonical jtorctl.
This sounds like a good plan!
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32303#comment:27>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list