[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: arma
Type: enhancement | Status: assigned
Priority: Medium | Milestone: Tor: unspecified
Component: Core Tor/Tor | Version: Tor: 0.3.4.9
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------+----------------------------------
Comment (by teor):
Replying to [comment:7 wagon]:
> > I'd like to build an abstraction layer over all available directory
documents (like #25999, but inside tor).
> I have another idea. We have some trade-off between internal Tor's
complexity and Tor's network performance. We need some balance which will
make Tor support and development effective and convenient.
>
> Microdescriptors were added to Tor code long time ago (10 years?), when
internet in general and Tor network in particular were 10-20 times slower
than now (you can check metrics graphs). Amount of Tor nodes increased
only 3 times during this period. Now we could remove this redundancy by
moving to single type descriptors which will be not as small as
microdescriptors but will be complete. We need de-duplication.
There are millions of tor clients, and they use microdescriptors and the
microdesc consensus (md) by default. So we need to minimise the size of md
documents.
There are thousands of relays, and a few special clients, authorities, and
tools. They use the full (networkstatus or ns) consensus and full
descriptors to get more details about relays. The size of these documents
does not matter that much, because they only go to a small number of
machines.
We have proposals that would create a new consensus flavour (picodesc
consensus? pd?) with fewer fields. Once all supported Tor versions use the
pd consensus, we can stop distributing the microdesc consensus. (Or, more
likely, distribute a md consensus containing no relays.)
> Then, on top of these simplified descriptors you could make some
abstraction layer for `ControlPort`. As concerns its current state, there
are also other issues, e.g. with
[[https://trac.torproject.org/projects/tor/ticket/28300#comment:4|status/version/num-{concurring,versioning}]]
and with
[[https://trac.torproject.org/projects/tor/ticket/28300#comment:6|"Option/*"]]
values (I'm not sure I have to create separate tickets about that).
Please open one ticket per bug. Otherwise, we lose track of bugs.
> P.S. I wonder why `ControlPort` can only be binded to loopback
interface. Is it a bug or feature? I assume that in some environments,
where Tor is controlled by a remote machine, it would be convenient to
bind to another IP than 127.0.0.1 (firewall redirection can be used to
overcome this difficulty, but direct binding is simpler to setup).
You can bind ControlPort to a non-local port, but you must have
authentication on:
https://github.com/torproject/tor/blob/2b2b97484ad07c91ac410735a96fe8710e60cf23/src/app/config/config.c#L6642
https://github.com/torproject/tor/blob/2b2b97484ad07c91ac410735a96fe8710e60cf23/src/app/config/config.c#L7376
> UPDATED: It would be convenient to have `ControlPort` commands explained
in some man page. Now they are described only in inline help `/help` and
in `control-spec.txt`.
I'm not sure how we could keep a man page and the control spec in sync,
without it taking a lot of effort.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28676#comment:8>
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