[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #24110 [Core Tor/Tor]: NS_CONTROL_PORT formats change when using microdescriptors
#24110: NS_CONTROL_PORT formats change when using microdescriptors
-------------------------------------------------+-------------------------
Reporter: teor | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: Tor:
| 0.3.3.x-final
Component: Core Tor/Tor | Version: Tor:
| 0.3.0.1-alpha
Severity: Normal | Resolution:
Keywords: bwauth-needs, tor-control, tor-spec | Actual Points:
Parent ID: | Points: 1
Reviewer: | Sponsor:
| SponsorV-can
-------------------------------------------------+-------------------------
Changes (by catalyst):
* keywords: bwauth-needs => bwauth-needs, tor-control, tor-spec
Old description:
> In Tor 0.3.0 (or earlier?), we made clients use microdescriptors by
> default. This changes the format of NS_CONTROL_PORT routerstatus lines,
> which breaks pytorctl, and therefore the bandwidth authorities.
>
> Apparently, this issue can be resolved by setting UseMicrodescriptors 0
> or using 0.2.9.
New description:
In Tor 0.3.0 (or earlier?), we made clients use microdescriptors by
default. This changes the format of NS_CONTROL_PORT routerstatus lines,
which breaks pytorctl, and therefore the bandwidth authorities.
Apparently, this issue can be resolved by setting UseMicrodescriptors 0 or
using 0.2.9.
edit: Let's update control-spec.txt to document the current (surprising)
behavior and track further behavior improvements in other tickets.
--
Comment:
Summarizing an IRC conversation with arma and Sebastian:
* The `UseMicrodescriptors=0` workaround seems to work for pytorctl (and
thus bwauths) for now.
* We probably should keep the `GETINFO ns/*` keys and `NS` async events
the same for backward compatibility, i.e., continue making them in the ns-
flavored format with a truncated SHA-256 hash in the descriptor digest
field if tor is using microdescriptors.
* There should probably be a new set of `GETINFO` keys and async events
that generalize router statuses in the control protocol, maybe `GETINFO
rs/*` and `RS` async events. The controller could explicitly request ns
and microdesc flavors of each.
* TODO: check whether it's possible for a single instance of tor to
download both ns- and microdescriptor-flavored consensuses.
I'm also thinking that we should scope this ticket to updating control-
spec.txt to describe the current (somewhat surprising) behavior and open
new tickets for the other related issues.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24110#comment:12>
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