[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #26970 [Core Tor/Tor]: Privcount: plan the modules and components

#26970: Privcount: plan the modules and components
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  teor
     Type:  task                                 |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.5.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  privcount, 035-roadmap-master, 035   |  Actual Points:
  -triaged-in-20180711, rust                     |
Parent ID:  #25669                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by teor):

 Replying to [comment:1 chelseakomlo]:
 > Ok, here are a few questions/clarifications:
 >
 > 1. Tor main codebase will include:
 > - The Rust "Data Collector" module
 > - Tools for creating/validating configuration.
 > Question: Will the configuration management tooling also be in Rust? Or
 will this be part
 of tor's existing configuration validation/etc?

 The configuration tool will probably be written in Rust, because the
 underlying config parser will be a rust module. We expect to maintain a
 small number (1-5) of configurations for the public tor network, at most
 one per supported tor release:

 https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases

 I don't think there is any value in letting relay operators configure
 their own statistics in detail, because each statistic requires
 accompanying Tor code. And letting operators configure noise amounts is
 dangerous to users. (But we might need some way of activating new
 statistics for testing.)

 > Will this configuration management be the same as for the Tally
 Reporter?

 I expect that Tally Reporters will use the same config format, and support
 the same small number of configurations as Tor.

 > 2. A separate pure-Rust binary
 > - This will be the "Tally Reporter"
 > Question: Will this binary be a sidecar to Tor relays, or will this be
 stand-alone (like a bwauth)?

 There will be a small number of tally reporters (5-9) for the public tor
 network. They will be standalone, like bandwidth authorities or CollecTor
 instances. Tally reporters do not need to be run on directory authorities.
 They take counters from relays, and publish aggregate results for metrics
 to consume.

 > How will this communicate with the Rust module in core tor?

 The Data Collector Rust module will produce the counters document format:
 https://gitweb.torproject.org/torspec.git/tree/proposals/288-privcount-
 with-shamir.txt#n222

 And then these documents will be uploaded to the Tally Reporters using a
 mechanism that we'll specify in a future proposal.

 For example, relays could upload counters documents to directory
 authorities, like they currently upload descriptors and extra-info
 documents:

 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n344

 Then Tally Reporters would download and process the counters documents.

 > Maybe the first step is to separate out these components (if they aren't
 already, apologies if I missed that)?

 Most of the modules and components don't exist yet.

 So I think we should design the modules that belong in the Data Collector
 and Tally Reporter, and see which ones will be shared.

 > The pure-Rust binary will be much easier, and reviewing it will be
 different than reviewing components that will integrate with C (for
 example, logging will be different, etc).

 > Maybe then the second step is to work on integrating the Rust "Data
 Collector" into core tor, and there we can do a review for the FFI layer,
 etc?

 I agree. I want to clean up the privcount_shamir code (it will be a shared
 module), and write the noise module. Then I think we will have enough code
 to integrate a simple counter into core Tor.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26970#comment:3>
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