[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: #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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs