wiki:org/meetings/2014WinterDevMeeting/notes/TorRoadmap

Our current Process for deciding what to do:

  • what we feel like doing
  • what we're funded to do
  • what somebody has written a proposal to do

Our current process for reviewing our own code:

  • Nick begs everybody

What are the important keys to deciding how our development goes, over the next 6-12 months?

Important: preventive and proactive security measures E.g.

  • hidden service redesign
  • relay crypto improvements

Proactive security stuff:

  • Tor is written in C. Let's improve tests, factoring, component isolation

Prioritize reviewing and merging-when-not-stupid incoming code, because new patches means new developers if we give them attention

Is one of our code review problems that we don't have a supporting tool? Gerritt is one example.

Dependencies on openssl, and other crypto libraries? Do we prioritize that?

Answer: we fixed the most important crypto / cipher stuff, when we changed the link encryption and the circuit handshake.

How can we provide "100 year crypto" style security?

Going to the bigger picture: should there be a roadmap at all?

We could make a roadmap about priorities -- guard nodes, circuit building, etc. Plus how long it will take to build each of them, etc.

Such a roadmap would be really handy for a funding proposal for core Tor stuff. Indeed, we could use funding for more than just Nick and Andrea.

Erinn would be happy to set up gerritt for us. It's unclear if that's actually the bottleneck, but let's get rid of it and then see.

What about using github? Nick finds github's workflow not productive, especially if we keep our trac (in which case we'd have two places we need to check, not the one that we're promised).

One of the huge features of github is that it attracts people who do code reviews, give us patches, etc.

One process option: reserve some time of your month for code review for each other's code.

One problem: it's not easy for people to find what needs review.

Answer: it's everything in trac that's in state needs_review.

A useful idea: should we have a ready_for_merge state, where once they've reviewed it, they indicate that they think it's ready for merge. Erinn volunteers to make this new trac state happen.

Jake: if we had a roadmap, where we can predict time or version of when our code will go in, volunteer devs like me would be more excited about contributing code.

Need a "How to do a code review" document, which includes "say whether you think it's mergeable or not". Many people review parts of the patch but don't feel confident making a statement about all of it.

Linus commits to working on a "how to usefully do Tor code review" document

Who and when to do the roadmap?

Plan: Andrea, Nick, Roger will flesh out the list of categories.

Roadmap categories:

  • Protocol security
    • guards
    • crypto migration
    • post-quantum
    • hide the directory authorities
    • what happens to our anonymity when we don't have a clique topology?
    • ddos resistance
  • Program security
    • tests
    • sandboxing
    • multiprocess sandboxing
    • capabilities
    • secure coding
  • Performance
  • Scalability
  • Reachability
  • Contributor documentation
  • Misc
Last modified 4 years ago Last modified on Feb 25, 2014, 2:13:22 PM