Nick's (current) Schedule and Commitments
2011
March
MARCH 15: Sponsor F
- #4685 (moved) : Revised proposal for extended ORPorts; implement it. George has a draft. (With George)
- #4958 (moved) : Revise proposal 179 (make SSL connections look more uniform. (With Jake)
- Also help with #4679 (moved) (Proposals for pluggable transports)
- Also help with #5010 (moved) (proposal for programs that learn bridge addresses)
- Also be available if Roger wants to talk about #4465 (moved), #4682 (moved), and #4506 (moved)
MARCH 31: Sponsor G
- Help with #4561 (moved) (Allow servers to have multiple addresses)
- Help with #4562 (moved) (development roadmap for pluggable transports)
- Help with #4563 (moved) (ipv6 for bridges)
MEANWHILE:
- Work on Milestone 0.2.3.x tickets
- Put out another 0.2.3.x release
April
May
MEANWHILE:
- For 0.2.4.x:
- Answer all pending proposals (XXXX make a list here)
- Write proposals as needed for stuff needed for 0.2.4.x
- Pick out important 0.2.4.x features in need of proposals.
- Merge "Finished" proposals into specs.
- For 0.2.3.x:
- Put out a Tor 0.2.3.x release
- Fork Tor maint-0.2.3
June
SPONSOR G, JUNE 30:
- Help with IPv6 stuff
- Help with Pluggable transports stuff.
July
August
September
SPONSOR G, SEP 30:
- Optional stuff, TBD.
October
November
SPONSOR F, TENATIVE:
- Evaluate Ian Goldberg's theory that we can get rid of stream-level congestion windows in the protocol; and then either write a proposal and do it, or write an explanation of why they're still useful. [Nick, Steven, Roger, other?]
- Internet drafts for one or two TLS features to improve its traffic-analysis resistance. In particular, TLS needs better support for link padding, and for a mode where it does not send its record headers as plaintext. (Yes, TLS implementation moves bog-slow, but if we can get extensions in place, or something into TLS 1.x, we can do a lot of good here.) [Nick]
- write a proposal for at what level of abstraction the "Tor does an SSL handshake with a real apache, posts a password over http to the server, and then gets passed to the real Tor relay" design should take place. Should the Tor client simply talk to a local proxy which does this dance, a la pluggable transports? Should Tor use a libevent2 filter? Something else? [Nick, others]
- evaluate feasibility of a python equivalent to obfsproxy, to make it easier for people to write transports in python. See also Brandon Wiley's "dust". If we decide it's smart, get it started. [Nick, George, Brandon, ?]
- pluggable transport: evaluate feasibility of a python equivalent to obfsproxy, to make it easier for people to write transports in python. See also Brandon Wiley's "dust". If we decide it's smart, get it started. [Nick, George, Brandon, ?]
- tor: Support for resolving destination names to IPv6 and exiting to IPv6 destinations. [Linus, Nick]