Re: [tor-bugs] #32125 [Applications/Tor Browser]: Using private obfs4 bridge does not show circuit display

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#32125: Using private obfs4 bridge does not show circuit display
-------------------------------------------------+-------------------------
 Reporter:  ggus                                 |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-circuit-display,                 |  Actual Points:  0.25
  TorBrowserTeam201910R                          |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by arma):

 Replying to [comment:8 pospeselr]:
 > Next, nodeDataForId() in tor-circuit-display.js skips over the 'bridge'
 section (as the result of getBridge() is null) and it assumes we are
 dealing with a relay. The failing {{{GETINFO ns/id/$fingerprint}}} call
 ends up throwing exception because we're passing in a bridge
 id/fingerprint which is not part of the consensus (according to arma). As
 a result, the IP of the relay is never set.

 Right -- getinfo ns/id/ calls router_get_consensus_status_by_id() on the
 digest, which hunts for the relay info among the response from
 networkstatus_get_latest_consensus(). But since bridges aren't (typically)
 in the consensus, you won't (typically) have any useful result here.

 I think the patch here is the right one in the short term, and maybe even
 in the long term too because of simplicity. But we should answer the
 question of "how controllers ought to handle this situation" on the Tor
 side, in case Tor Browser or somebody else wants to do it in the future.
 For example, check out "getinfo /ns/purpose/bridge" as a potentially
 useful building block: it asks Tor to fabricate a status entry like one
 would find in the consensus, for each of its current bridges. But maybe
 there is an even better way. I've opened #32157 to move this question
 forward on the Tor side.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32125#comment:9>
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