[tor-bugs] #32157 [Core Tor/Tor]: When bridges lines leave out the fingerprint, how should controllers look them up by id?

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Oct 19 07:00:07 UTC 2019


#32157: When bridges lines leave out the fingerprint, how should controllers look
them up by id?
--------------------------+------------------------
 Reporter:  arma          |          Owner:  (none)
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------

Comment (by arma):

 One option that comes to mind is that when we learn the fingerprint as we
 connect to the bridge, inside learned_router_identity(), we could emit a
 controller event. Then controllers that are listening could annotate their
 internal state of our bridges on their own, when they see the event. I
 believe we don't have any event like that currently though. And this idea
 wouldn't by itself be enough, because controllers only hear controller
 events when they're already connected, so we would want some way for the
 controller to ask for the current state.

 I found "getinfo ns/purpose/bridge", which asks Tor to fabricate a status
 entry like one would find in the consensus, for each of its current
 bridges:
 {{{

 getinfo ns/purpose/bridge
 250+ns/purpose/bridge=
 r badabim GUj+xxxxxxxxRWt9ucLTfvtyUME lsA8xxxxxxxxB1DIMFPusxQIZsk
 2019-10-19 04:30:28 x.y.153.221 9001 0
 s Running V2Dir
 w Bandwidth=1215
 p reject 1-65535
 .
 250 OK
 }}}
 This is essentially how the bridge authority makes a faux networkstatus
 document for all the bridges it knows (for export to bridgedb). So we
 could tell controllers, if they have a relay id and they can't find it in
 getconf bridge and they can't find it in getinfo ns/id/, to ask for
 getinfo ns/purpose/bridge and crawl through those results.

 Is that our best available option? Is there some better way we should
 expose this info?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32157#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list