[tor-bugs] #16276 [Onionoo]: bug in onionoo's family set detection

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Jun 17 20:00:06 UTC 2015


#16276: bug in onionoo's family set detection
-----------------------------+-----------------
     Reporter:  cypherpunks  |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Onionoo      |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+-----------------

Comment (by karsten):

 First of all, you're right that having both `"family"` and
 `"effective_family"` fields is a contradiction to the redundancy
 statement.  The primary idea of leaving `"family"` untouched was to be
 backwards-compatible, and the argument of avoiding redundancy was supposed
 to avoid yet another field with the declared family members that did
 ''not'' make it into the family.

 Regarding your first comment about detecting misconfigurations, the goal
 would be to do this with a single details document for a given relay.
 When Atlas or Globe display the details, they should have an easy way to
 detect misconfigurations in the relay's family configuration.  It's easy
 for them to compute set diffs, so we wouldn't have to pre-compute a set of
 unused family members for them.  That's what I meant by "not a service
 used by humans".  The approach you mention might be too complicated for
 Atlas/Globe.  All they do is display data, and that's okay.

 About your comment about considering worst cases, I agree that this might
 get more complex than expected.  And maybe we're overengineering this.
 Maybe the better solution would be to make that backward-incompatible
 change where we only list effective family members in the `"family"`
 field.  All I say is that this would require a major protocol change and 1
 or 2 months time for Onionoo clients to adapt.  But maybe it's the better
 way, because people (in this case Onionoo client developers) won't be
 confused by two different family fields.

 By the way, my plan was indeed to update effective family sets every hour.
 We already update details files of all running relays and of all relays
 that just stopped running.  Computing those sets every hour shouldn't be
 difficult.

 How do we proceed?  What's your favorite solution?  And would you want to
 start hacking on this?

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


More information about the tor-bugs mailing list