[tor-bugs] #32534 [Applications/Tor Browser]: settle on one canonical jtorctl
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Nov 19 15:19:08 UTC 2019
#32534: settle on one canonical jtorctl
-------------------------------------------------+-------------------------
Reporter: eighthave | Owner: tbb-
| team
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: Android, tbb-mobile, jtorctl, | Actual Points:
TorBrowserTeam202001 |
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by eighthave):
@sisbell mention that Tor Browser uses
net.freehaven.tor.control:jtorctl:0.2, then makes a custom subclass of
`TorControlConnection`. Here's the tricky part: the `TorService` needs a
way to reliably broadcast when Tor is started, meaning apps can use it to
make network connections. The only way I've seen to do that is using the
ControlPort via a `TorControlConnection` instance. That means that
`TorService` needs to use its own `TorControlConnection` instance.
jtorctl only supports a single `TorControlConnection` instance. Then all
the bits that the Android apps need come via Android methods, like
broadcast `Intent`s.
From what I've seen in Orbot, this is doable. I haven't seen Tor
Browser's custom `TorControlConnection`. But this would be doable if Tor
Browser's custom `TorControlConnection` was upstreamed into a new jtorctl
release. As far as I've seen, jtorctl should be the Java representation
of all the commands available on the ControlPort. So making jtorctl
canonical would be the way to implement that.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32534#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list