[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

#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:  #7646         |         Points:
 Reviewer:                |        Sponsor:
--------------------------+----------------------------------

Comment (by wagon):

 Now I think the picture is more clear, so I'll reply to myself and to
 above comments.

 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. 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?
 In any case, I wonder why it doesn't update the content of the file
 `cached-microdesc-consensus`. 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.
 >
 > 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 guess, when `UseMicrodescriptors` is set to 0,
 Tor just continue to use microdescriptors, 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).

 "Descriptor" is mostly what replay publishes about himself. "Consensus" is
 mostly the result of agreement between authorities about a relay. These
 types of information indeed complement each other. In some parts it may be
 counter-intuitive. For example, it looks natural for a relay to decide if
 he wants to be an Exit or a middleman, but actually some flags are judged
 by authorities, also an an Exit flag. Similarly, bandwidth is judged by
 bandwidth authorities. Thus, descriptor (or its reduced version
 "microdescriptor") doesn't have this information just because it comes
 from another source.

 When microdescriptors are used, they are stored in `cached-microdescs*`
 file(s). "Consensus" is stored in `cached-microdesc-consensus`. Similarly,
 when `UseMicrodesriptor` is 0, descriptors are stored in `cached-
 descriptors*` file(s), while "consensus" is stored in `cached-consensus`.
 So, if `UseMicrodesriptor` is 0, relay flags and bandwidth are indeed
 stored at disk, but in `cached-consensus`, not `cached-microdesc-
 consensus`, and `cached-microdesc-consensus` is not updated. Thus, actual
 question would be why Tor now needs to support two different files
 `cached-consensus` and `cached-microdesc-consensus`, when their content is
 mostly the same. I guess the current status quo can be explained by
 historical reasons to get smooth transition from descriptors to
 microdescriptors. #7646 is a more proper ticket for general discussions
 about these things.

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