TODO 9.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220
  1. $Id$
  2. Legend:
  3. SPEC!! - Not specified
  4. SPEC - Spec not finalized
  5. NICK - nick claims
  6. ARMA - arma claims
  7. PHOBOS - phobos claims
  8. - Not done
  9. * Top priority
  10. . Partially done
  11. o Done
  12. D Deferred
  13. X Abandoned
  14. Non-Coding, Soon:
  15. N - contact umass folks
  16. N - Mention controller libs someplace.
  17. D FAQ entry: why gnutls is bad/not good for tor
  18. P - flesh out the rest of the section 6 of the faq
  19. P - gather pointers to livecd distros that include tor
  20. - put the logo on the website, in source form, so people can put it on
  21. stickers directly, etc.
  22. - more pictures from ren. he wants to describe the tor handshake, i want to
  23. talk about hidden services.
  24. * clean up the places where our docs are redundant (or worse, obsolete in
  25. one file and correct elsewhere). agl has a start on a global
  26. list-of-tor-docs.
  27. P - update windows docs to clarify which versions of windows, and why a
  28. DOS window, how it's used, for the less technical users
  29. NR- write a spec appendix for 'being nice with tor'
  30. - tor-in-the-media page
  31. - Ask schanzle@cas.homelinux.org about a patch for rpm spec fixes against
  32. tor-0.1.0.7.rc
  33. - Remove need for HACKING file.
  34. for 0.1.1.x:
  35. R - are dirservers auto-verifying duplicate nicknames?
  36. - tor should auto-sort the recommended-versions strings
  37. (with the new smartlist sort stuff maybe)
  38. - setconf SocksBindAddress kills tor if it fails to bind
  39. N - controller libs should support resetconf command.
  40. N . Additional controller features
  41. - Find a way to make event info more extensible
  42. - change circuit status events to give more details, like purpose,
  43. whether they're internal, etc.
  44. . Expose more information via getinfo:
  45. - import and export rendezvous descriptors
  46. - Review all static fields for additional candidates
  47. - Allow EXTENDCIRCUIT to unknown server.
  48. - We need some way to adjust server status, and to tell tor not to
  49. download directories/network-status, and a way to force a download.
  50. - It would be nice to request address lookups from the controller
  51. without using SOCKS.
  52. . Helper nodes
  53. . More testing and debugging
  54. - On sighup, if usehelpernodes changed to 1, use new circuits?
  55. - If your helper nodes are unavailable, don't abandon them unless
  56. other nodes *are* reachable.
  57. R - If you think an OR conn is open but you can never establish a circuit
  58. to it, reconsider whether it's actually open.
  59. - Miscellaneous cleanups
  60. - switch accountingmax to count total in+out, not either in or
  61. out. it's easy to move in this direction (not risky), but hard to
  62. back, out if we decide we prefer it the way it already is. hm.
  63. . Come up with a coherent strategy for bandwidth buckets and TLS. (The
  64. logic for reading from TLS sockets is likely to overrun the bandwidth
  65. buckets under heavy load. (Really, the logic was never right in the
  66. first place.) Also, we should audit all users of get_pending_bytes().)
  67. - Make it harder to circumvent bandwidth caps: look at number of bytes
  68. sent across sockets, not number sent inside TLS stream.
  69. R - remove the warnings from rendezvous stuff that shouldn't be warnings.
  70. N . Handle rendezvousing with unverified nodes.
  71. o Implement everything
  72. . Enable the new code
  73. . Verify that new code works.
  74. - Christian Grothoff's attack of infinite-length circuit.
  75. the solution is to have a separate 'extend-data' cell type
  76. which is used for the first N data cells, and only
  77. extend-data cells can be extend requests.
  78. - Specify, including thought about
  79. - Implement
  80. N - Destroy and truncated cells should have reasons.
  81. N - Add private:* alias in exit policies to make it easier to ban all the
  82. fiddly little 192.168.foo addresses.
  83. (AGL had a patch; consider applying it.)
  84. N - warn if listening for SOCKS on public IP.
  85. - cpu fixes:
  86. - see if we should make use of truncate to retry
  87. o hardware accelerator support (configure engines.)
  88. - hardware accelerator support (use instead of aes.c when reasonable)
  89. R - kill dns workers more slowly
  90. . Directory changes
  91. o recommended-versions for client / server ?
  92. - Some back-out mechanism for auto-approval
  93. - dirservers have blacklist of IPs they hate
  94. - a way of rolling back approvals to before a timestamp
  95. - have new people be in limbo and need to demonstrate usefulness
  96. before we approve them
  97. - other?
  98. R . Dirservers verify reachability claims
  99. o basic reachability testing, influencing network-status list.
  100. R - rate-limiting the reporting of trouble servers
  101. R - check reachability as soon as you hear about a new server
  102. - Decentralization
  103. - Figure out what to do about hidden service descriptors.
  104. - find 10 dirservers.
  105. - (what are criteria to be a dirserver?)
  106. o Dirservers publish compressed network-status objects.
  107. o Support retrieving several-at-once
  108. o Everyone downloads network-status objects
  109. N . Clients: from all directories, round-robin
  110. o Basic implementation: disable until 0.1.1.6 is out.
  111. - On failure, mark trusted_dir_server as having failed once and
  112. retry up to a point.
  113. o Parse them
  114. o Cache them, reload on restart
  115. o Serve cached directories
  116. o Directories expose individual descriptors
  117. X By 'if-newer-than' (Does the spec require this??)
  118. o Support compression.
  119. N - Alice acts on network-status objects
  120. - Alice downloads descriptors as needed.
  121. - Alice sets descriptor status from network-status
  122. - Security
  123. - Alices avoid duplicate class C nodes.
  124. - Analyze how bad the partitioning is or isn't.
  125. N - Naming:
  126. - Separate naming from validation in authdirs.
  127. - Clients choose names based on network-status options.
  128. - Names are remembered in client status.
  129. - packaging and ui stuff:
  130. . multiple sample torrc files
  131. - uninstallers
  132. . for os x
  133. . something, anything, for sys tray on Windows.
  134. . figure out how to make nt service stuff work?
  135. . Document it.
  136. . Add version number to directory.
  137. N - Vet all pending installer patches
  138. - Win32 installer plus privoxy, sockscap/freecap, etc.
  139. - Vet win32 systray helper code
  140. Reach (deferrable) items for 0.1.1.x:
  141. - Start using create-fast cells as clients
  142. o Let more config options (e.g. ORPort) change dynamically.
  143. - start handling server descriptors without a socksport?
  144. o Add TTLs to DNS-related replies, and use them (where present) to adjust
  145. addressmap values.
  146. . Research memory use on Linux: what's happening?
  147. - Is it threading? (Maybe, maybe not)
  148. - Is it the buf_shrink bug? (Quite possibly)
  149. - Instrument the 0.1.1 code to figure out where our memory is going;
  150. apply the results. (all platforms?)
  151. For 0.1.1.x, if we can figure out how:
  152. - rewrite how libevent does select() on win32 so it's not so very slow.
  153. o enclaves (at least preliminary)
  154. - Write limiting; separate token bucket for write
  155. - Audit everything to make sure rend and intro points are just as likely to
  156. be us as not.
  157. - Do something to prevent spurious EXTEND cells from making middleman
  158. nodes connect all over. Rate-limit failed connections, perhaps?
  159. Future version:
  160. - Limit to 2 dir, 2 OR, N SOCKS connections per IP.
  161. - Handle full buffers without totally borking
  162. - Rate-limit OR and directory connections overall and per-IP and
  163. maybe per subnet.
  164. - Hold-open-until-flushed now works by accident; it should work by
  165. design.
  166. - DoS protection: TLS puzzles, public key ops, bandwidth exhaustion.
  167. - Specify?
  168. - tor-resolve script should use socks5 to get better error messages.
  169. - make min uptime a function of the available choices (say, choose 60th
  170. percentile, not 1 day.)
  171. - config option to publish what ports you listen on, beyond ORPort/DirPort
  172. - hidserv offerers shouldn't need to define a SocksPort
  173. * figure out what breaks for this, and do it.
  174. - auth mechanisms to let hidden service midpoint and responder filter
  175. connection requests.
  176. - Relax clique assumptions.
  177. - tor should be able to have a pool of outgoing IP addresses
  178. that it is able to rotate through. (maybe)
  179. Blue-sky:
  180. - Patch privoxy and socks protocol to pass strings to the browser.
  181. - Standby/hotswap/redundant hidden services.
  182. - Robust decentralized storage for hidden service descriptors.
  183. - The "China problem"
  184. - Allow small cells and large cells on the same network?
  185. - Cell buffering and resending. This will allow us to handle broken
  186. circuits as long as the endpoints don't break, plus will allow
  187. connection (tls session key) rotation.
  188. - Implement Morphmix, so we can compare its behavior, complexity, etc.
  189. - Other transport. HTTP, udp, rdp, airhook, etc. May have to do our own
  190. link crypto, unless we can bully openssl into it.
  191. - Conn key rotation.
  192. - Need a relay teardown cell, separate from one-way ends.
  193. (Pending a user who needs this)
  194. - Handle half-open connections: right now we don't support all TCP
  195. streams, at least according to the protocol. But we handle all that
  196. we've seen in the wild.
  197. (Pending a user who needs this)