Re: [tor-bugs] #19327 [Core Tor/Tor]: controller: expose fine-grained circuit detail.

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

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