Re: [tor-bugs] #25999 [Core Tor/Stem]: Build an abstraction layer over different consensus flavours

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

#25999: Build an abstraction layer over different consensus flavours
---------------------------+-----------------------------------
 Reporter:  teor           |          Owner:  atagar
     Type:  enhancement    |         Status:  needs_information
 Priority:  Medium         |      Milestone:
Component:  Core Tor/Stem  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  descriptor     |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:                 |        Sponsor:
---------------------------+-----------------------------------

Comment (by teor):

 Replying to [comment:1 atagar]:
 > Hi teor. I'm a little unclear, are you asking for the consensus class to
 call controller methods to fetch microdescritpors?

 No, I'm asking for Stem (or Tor) to provide a class that abstracts over
 the differences between ns consensuses, full relay descriptors, microdesc
 consensuses, and microdescriptors.

 The class should be generic, so it can take a stem.descriptor.remote
 instance, or a controller, or a list of directory document objects (or
 maybe even a data directory?).

 For example, when I ask this class for a relay's IPv6 address:
 * if there is a ns consensus containing that relay, use that IPv6 address,
 or
 * if there is a microdesc consensus containing that relay, and the
 consensus method is 27 or later, use that IPv6 address, or
 * if there is a full descriptor for that relay, use that IPv6 address, or
 * if there is a microdescriptor for that relay, and the consensus method
 is 27 or earlier, use that IPv6 address.

 IPv6 is one of the most complicated cases, because it moved between
 directory documents.

 Here's a simpler example:

 If I ask this class for a relay's ed25519 id:
 * if there is a ns consensus containing that relay, use that ed25519 id,
 or
 * if there is a full descriptor for that relay, use that ed25519 id, or
 * if there is a microdescriptor for that relay, use that ed25519 id.

 > The proper solution I suspect is for tor to provide two controller
 methods so it's unambiguous what kind of consensus the caller gets.

 That's a good idea, but it doesn't solve the problem on clients, which
 only have one type of consensus. And it doesn't solve the general issue,
 which is that people need to know where relay attributes are located
 before they can write correct stem code.

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