Changes between Initial Version and Version 1 of org/meetings/2014WinterDevMeeting/notes/TorRoadmapAndProcess

Feb 17, 2014, 2:24:46 PM (6 years ago)



  • org/meetings/2014WinterDevMeeting/notes/TorRoadmapAndProcess

    v1 v1  
     2Tor Roadmap
     4Opening Comments
     5- process of developing Tor has been crisis driven, funding driven, implementation
     6- incoming patch review has been sporadic
     7- process of intenral code review has been based on begging
     8- What are the lreally important things for little-t Tor for process of dev over 6-12 months?
     10Most important ideas
     11- proactive, preventative security measures
     12- performance is good, but lower priority
     13- focus on hidden service redesign, relay crypto improvements, things that material improve security
     14- This is a program written in (pretty good) C - need to improve tests, factoring, component isolation
     15- We need C code that people that are paranoid can feel better about running
     16- Improve process for reviewing new patches b/c new patches = new developers
     18Are you open to adding new libraries, tools for code review process?
     19something like Gerritt, happy to use, if someone can install; more convenient than reading code by hand
     21Any work to address key length, crypto library depencies etc?
     22Work has been done on improving key length, ECC support for forward secrecy; look towards quantum computing
     24- 100 year crypto problem is one that might be worthwhile to tackle, to have a roadmap in 10 or 20 years down the road
     25- There is no roadmap! Things that only exist as vague intentions and desires, in peoples heads... should they be turned into a roadmap?
     27- It is beneficial to identity important things to do (i.e. see "most important ideas" above)
     28- Roadmap would be very important to have for funding of direct researcher and development on Tor
     29- Need more C developers!
     31Need to make improvements to code review to improve participation, usability... what about Github?
     32Github is possible as a code review tool, though pull request system is tricky, especially if not synced with Trac tickets
     34- problem with Tor hosted projects is that you need an account; github is more social, encourages interaction
     36What is code review?
     37Process to ensure that random code does not get integrated just by one person; have someone else review, look for side effects, is it testable?
     39Can we establish a code review process?
     40Ask each for code reviews when we are not crazy busy!
     41Ian 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."
     43- Gerrit can tie into OpenID/LDAP so tie into Trac; looking into doing an anonymous account
     44- 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
     45- 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
     46- OONIProbe development does use Github, automated build, runs unit test, then code review happens by a human, who then merges
     47- Tor process: someone submits a patch, somewhere else reviews the patch, and then nick merges
     49- Nick maybe can reserve some time each month for code reviews, so that people know when it is a good time to submit/share
     50- 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
     51- Feel free to ask Nick "what work can I do for you!?" :)
     53- 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"
     55- 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
     57- 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
     59- who and when to build these cats? (cats?!)
     61- let's write down the eight important ideas for Tor, and people can fill in under the categories, to help prioritize the discussion
     63- Some became demotivated to work on something that had dependencies that would not be added to core tor, and so stopped working on them
     64- Need to discuss states about being non-scared of dependencies; If we had a roadmap that laid out a particular time for a feature
     66- We should rely on cryptographers real ideas, not leakers  (possibly)
     68High-Level Roadmap
     691. Protocol Security (replace bad crypto, guards, post-quantum, DDoS, ipv6)
     702. Program Security (better tests, better sandboxing, more secure coding, priv separation)
     713. Address Theoretical Concerns (that aren't outright crazy)
     724. Performance, Scalability
     735. Reachability (tor clients to relays, tor relays to tor relays, ipv6!)
     746. Documentation!?
     76- peer to peer designs are ones that move away from directory authorities and relays
     77- we need a human being to expand list into roadmap-y topics into paragraph structure, narrative, user stories
     79Action Items
     80- Nick will begin roadmap, needs a human helper
     81- Erinn will setup Gerritt and new Trac states for merge
     82- Setup core review page on the wiki or in doc/hacking