Version 1 (modified by n8fr8, 6 years ago) (diff)


Tor Roadmap

Opening Comments

  • process of developing Tor has been crisis driven, funding driven, implementation
  • incoming patch review has been sporadic
  • process of intenral code review has been based on begging
  • What are the lreally important things for little-t Tor for process of dev over 6-12 months?

Most important ideas

  • proactive, preventative security measures
  • performance is good, but lower priority
  • focus on hidden service redesign, relay crypto improvements, things that material improve security
  • This is a program written in (pretty good) C - need to improve tests, factoring, component isolation
  • We need C code that people that are paranoid can feel better about running
  • Improve process for reviewing new patches b/c new patches = new developers

Are you open to adding new libraries, tools for code review process? something like Gerritt, happy to use, if someone can install; more convenient than reading code by hand

Any work to address key length, crypto library depencies etc? Work has been done on improving key length, ECC support for forward secrecy; look towards quantum computing

  • 100 year crypto problem is one that might be worthwhile to tackle, to have a roadmap in 10 or 20 years down the road
  • There is no roadmap! Things that only exist as vague intentions and desires, in peoples heads... should they be turned into a roadmap?
  • It is beneficial to identity important things to do (i.e. see "most important ideas" above)
  • Roadmap would be very important to have for funding of direct researcher and development on Tor
  • Need more C developers!

Need to make improvements to code review to improve participation, usability... what about Github? Github is possible as a code review tool, though pull request system is tricky, especially if not synced with Trac tickets

  • problem with Tor hosted projects is that you need an account; github is more social, encourages interaction

What is code review? Process to ensure that random code does not get integrated just by one person; have someone else review, look for side effects, is it testable?

Can we establish a code review process? Ask each for code reviews when we are not crazy busy! Ian G says "read the patch entirely. reason about the context of the patch. reason of the context in context of what we are trying to accomplish. then think about if they do them well."

  • Gerrit can tie into OpenID/LDAP so tie into Trac; looking into doing an anonymous account
  • Linux kernel is an old style of sending to a mailing list; they sign-off, ack bye, push every patch on list... question is not tools we use, but the process that we establish
  • ChromeOS/chromium has an automated patch process to show if things compiled, then escalated to a human review process, then to some auto build process
  • OONIProbe development does use Github, automated build, runs unit test, then code review happens by a human, who then merges
  • Tor process: someone submits a patch, somewhere else reviews the patch, and then nick merges
  • Nick maybe can reserve some time each month for code reviews, so that people know when it is a good time to submit/share
  • It is hard to know what needs to be reviewed at a given time; but it is hard to tell what... look in Trac in "needs review" state tickets
  • Feel free to ask Nick "what work can I do for you!?" :)
  • need to create a wiki page about the code review process; need clear process i.e. "say if you think it is mergeable or not"
  • some tickets are marked "need review" but have some comments on them, so we don't know if they are ready to merge; add a "needs merge" state
  • it is difficult to do code review completely - some people can review C code, but not qualified to ensure it is safe for all Tor code
  • who and when to build these cats? (cats?!)
  • let's write down the eight important ideas for Tor, and people can fill in under the categories, to help prioritize the discussion
  • Some became demotivated to work on something that had dependencies that would not be added to core tor, and so stopped working on them
  • Need to discuss states about being non-scared of dependencies; If we had a roadmap that laid out a particular time for a feature
  • We should rely on cryptographers real ideas, not leakers (possibly)

High-Level Roadmap

  1. Protocol Security (replace bad crypto, guards, post-quantum, DDoS, ipv6)
  2. Program Security (better tests, better sandboxing, more secure coding, priv separation)
  3. Address Theoretical Concerns (that aren't outright crazy)
  4. Performance, Scalability
  5. Reachability (tor clients to relays, tor relays to tor relays, ipv6!)
  6. Documentation!?
  • peer to peer designs are ones that move away from directory authorities and relays
  • we need a human being to expand list into roadmap-y topics into paragraph structure, narrative, user stories

Action Items

  • Nick will begin roadmap, needs a human helper
  • Erinn will setup Gerritt and new Trac states for merge
  • Setup core review page on the wiki or in doc/hacking