#19327: controller: expose fine-grained circuit detail. -------------------------------------------------+------------------------- Reporter: nickm | Owner: (none) Type: enhancement | Status: | needs_review Priority: Medium | Milestone: Tor: | unspecified Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: tor-control isolation test-support | Actual Points: intro | Parent ID: #17284 | Points: 2 Reviewer: nickm | Sponsor: | SponsorS-can -------------------------------------------------+-------------------------
Comment (by nickm): This is an interesting design question: do we want to expose everything here, or just stuff where we have a specific use-case for having it? Ideally, we should only expose things where any implementation of the Tor protocol might also want to expose them. I'd suggest ignoring isolation stuff for now, since there is work on progress for that stuff with ticket #19859. That includes all the stuff isolate_*, nym_epoch, and the things between client_proto_type and associated_isolated_stream_global_id in the source code. If we expose those, we'll want to do so in some way that's compatible with how we expose the same information for streams. For implementation strategy, I suggest the following: * Let's pick an fields set of options to add. Probably some of the above fields will be easier and * Then, let's get documentation for control-spec.txt that explains the new fields, so we can make sure that we are explaining them right. This is spec documentation, so it needs to explain what the fields are _guaranteed_ to mean, not what they actually mean in today's Tor. If there are any fields that might go away in the future, let's document that too. * Once that's settled, let's figure out how we do tests for these. One option is a unit test that constructs a dummy origin_circuit_t object and calls the appropriate function to serialize it for a controller. Another option would be a new test in Stem. * Once we have a specification and a testing strategy, let's start merging the new fields. Let's do a branch that implements just one or two of them at first, so that we can make sure we're on the sampe page about implementation and testing strategy. After that's done, we can figure out our best approach for doing the rest. (Next I'll look at each of the options you mentioned above and make some suggestions.) -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19327#comment:13> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs