[tor-bugs] #28676 [Core Tor/Tor]: Tor versions of Tor nodes should be accessible through ControlPort

[Tor Bug Tracker & Wiki]

#28676: Tor versions of Tor nodes should be accessible through ControlPort
--------------------------+----------------------------------
 Reporter:  wagon         |          Owner:  (none)
     Type:  enhancement   |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |        Version:  Tor: 0.3.4.9
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:  #24110        |         Points:
 Reviewer:                |        Sponsor:
--------------------------+----------------------------------

Comment (by teor):

 Replying to [comment:18 wagon]:
 > There is a command `GETINFO dir/status-vote/current/consensus` which
 returns the same output as the content of the file `cached-microdesc-
 consensus`. So, it has Tor versions of all nodes. However, output of this
 command is very big, so tools which use `ControlPort` may not behave
 nicely if this command is run often.
 >
 > This command works even if `UseMicrodescriptors` is set to 0.

 This command gets the full (ns) consensus from disk, so it *only* works if
 one of the following conditions is true:
 * `UseMicrodescriptors` is set to 0, or
 * the Tor instance is a directory cache, or
 * the Tor instance is a directory authority, or
 * the Tor instance is using a data directory that previously downloaded a
 full consensus. This full consensus may be outdated.

 > I don't know what this command is exactly doing. Does it query local
 cache or download these "microdescriptors" from network every time it is
 running?

 It gets the latest full (ns) consensus which the Tor instance has on disk:
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n807
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3862

 > In any case, I wonder why it doesn't update the content of the file
 `cached-microdesc-consensus`.

 There are two answers to that question:
 1. Use `GETINFO dir/status-vote/current/consensus-microdesc` gets the
 microdesc consensus.
 2. Tor updates the consensus flavour(s) that it is using or caching at
 random every hour or two.

 > Apart from this command there are commands `ns/id/FINGERPRINT` and
 `ns/all`, where the latter prints almost the same as `dir/status-
 vote/current/consensus`, but without Tor versions and global
 headers/footers. The commands `dir/status-vote/current/consensus` and
 `ns/all` mostly duplicate each other.

 "ns" is a backwards-compatible command that used to serve v2 consensuses,
 but now serves v3 consensuses:
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n614

 > Initially I understood descriptor as a "complete" version of
 microdescriptor, but this doesn't look correct. "Full" descriptors, which
 can be learnt separately by `desc/id/FINGERPRINT` or all together by `desc
 /all-recent`, don't contain final bandwidth and relay flags that
 "microdescriptor" has.

 I think you're confusing microdescriptors and the microdescriptor
 consensus.

 Microdescriptors are a subset of full descriptors:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1442

 And the microdescriptor *consensus* is a subset of the full consensus,
 with added microdescriptor hashes:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3261

 > I guess, when `UseMicrodescriptors` is set to 0, Tor just continue to
 use microdescriptors,

 No, Tor stops using microdescriptors for circuits when
 `UseMicrodescriptors` is set to 0.

 > but stops updating microdescriptors local file `cached-microdesc-
 consensus`. So, microdescriptors and descriptors look as mutually
 complementing each other, where microdescriptor mostly has parameters
 useful for clients, while descriptor has parameters mostly useful for
 relays (I may be totally wrong).

 It might help to read the parts of dir-spec that I linked above.

 > Thus, technically, as concerns this ticket, Tor versions of relays
 **can** be obtained from `ControlPort`, but I doubt the way, how Tor
 provides it, is convenient for Tor controllers. According to my opinion,
 this ticket is still valid.

 No-one has disagreed with you except yourself.
 We just need to specify how it will work, then implement it:
 https://trac.torproject.org/projects/tor/ticket/28676?replyto=18#comment:2

 > > I'd like to build an abstraction layer over all available directory
 documents (like #25999, but inside tor).
 > If there is a ticket about it, write a link, please.

 #27248 would be the first step. There isn't a ticket for updating the
 controller interface.

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