[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #32534 [Applications/Tor Browser]: settle on one canonical jtorctl
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs