TODO.021 16 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357
  1. $Id: TODO 16258 2008-07-30 13:04:38Z nickm $
  2. Legend:
  3. SPEC!! - Not specified
  4. SPEC - Spec not finalized
  5. N - nick claims
  6. R - arma claims
  7. P - phobos claims
  8. S - Steven claims
  9. E - Matt claims
  10. M - Mike claims
  11. J - Jeff claims
  12. I - ioerror claims
  13. W - weasel claims
  14. K - Karsten claims
  15. - Not done
  16. * Top priority
  17. . Partially done
  18. o Done
  19. d Deferrable
  20. D Deferred
  21. X Abandoned
  22. =======================================================================
  23. Things Roger would be excited to see:
  24. Nick
  25. - Finish buffer stuff in libevent; start using it in Tor.
  26. - Tors start believing the contents of NETINFO cells.
  27. . Work with Steven and Roger to decide which parts of Paul's project
  28. he wants to work on.
  29. - respond to Steven's red-team TLS testing (a.k.a, look at a packet
  30. dump and compare)
  31. Matt
  32. - Fit Vidalia in 640x480 again.
  33. - When user changes the language in Vidalia, have it change right then.
  34. - Vidalia should display/edit PlaintextPorts events/config.
  35. . Vidalia's GUI should let you specify an http proxy that it launches
  36. for you. Maybe in the general config window next to which Tor it
  37. launches for you.
  38. - Vidalia should avoid stomping on your custom exit policy lines
  39. just because you click on 'save' for a totally different config thing.
  40. - How much space do we save in TBB by stripping symbols from Vidalia
  41. first? Good idea or crazy idea?
  42. ioerror
  43. - gmail auto responder so you send us an email and we send you a Tor
  44. binary. Probably needs a proposal first.
  45. - weather.torproject.org should go live.
  46. o Learn from Steven how to build/maintain the Tor Browser Bundle.
  47. - Keep advocating new Tor servers and working with orgs like Mozilla
  48. to let them like Tor.
  49. - Start converting critical wiki pages into real Tor wml pages. E.g.,
  50. https://wiki.torproject.org/noreply/TheOnionRouter/VerifyingSignatures
  51. - Find out what happened to the buildbot and get it back up:
  52. http://tor-buildbot.freehaven.net:8010/
  53. - Learn about locking memory pages that have sensitive content. Get
  54. that started in Tor.
  55. - Translation portal
  56. - Vidalia html help files
  57. - should we i18nize polipo's error messages too?
  58. - Some of our translated wml files are very old -- so old that they
  59. are harmful to leave in place. We need some sort of way to notice
  60. this and disable them.
  61. Steven
  62. - Figure out (or give up on) how to run Tor Browser and ordinary
  63. Firefox side-by-side.
  64. - Enumerate and analyze traces left when running from USB
  65. - Write a list of research items Tor would like to see done, for the
  66. volunteer page. Pick a few you'd like to work on yourself.
  67. - Move proposal 131 or equivalent forward.
  68. - Keep bugging us about exploits on the .exit notation.
  69. - If relays have 100KB/s but set relaybandwidthrate to 10KB/s, do your
  70. interference attacks still work?
  71. - Mike's question #3 on https://www.torproject.org/volunteer#Research
  72. - Worthwhile shipping TBB with some local html help files that come
  73. as bookmarks?
  74. - Decide whether TBB should use Torbutton's "lock" feature.
  75. http://archives.seul.org/or/cvs/Jun-2008/msg00186.html
  76. Andrew
  77. - Which bundles include Torbutton? Change the docs/tor-doc-foo pages
  78. so they admit that Torbutton is in them too. Change the download
  79. page too.
  80. - The OS X bundle screenshots are from forever ago -- they don't
  81. include Torbutton, they still say it's tor.eff.org, etc.
  82. - Should we still be telling you how to use Safari on OS X for Tor,
  83. given all the holes that Torbutton-dev solves on Firefox?
  84. Karsten
  85. o Make a hidden services explanation page with the hidden service
  86. diagrams. See img/THS-[1-6].png. These need some text to go along
  87. with them though, so people can follow what's going on.
  88. - We should consider a single config option TorPrivateNetwork that
  89. turns on all the config options for running a private test tor
  90. network. having to keep updating all the tools, and the docs,
  91. just isn't working.
  92. Weasel
  93. - Figure out how to make Vidalia and Tor play nicely on Debian, make
  94. the necessary modifications, and make some Vidalia debs that pass
  95. muster.
  96. - Fix bug 393.
  97. - Get oftc to switch to Tor dns bulk exitlist. Or tell us why it's
  98. not suitable yet.
  99. - Take non-Running entries out of the networkstatus consensus.
  100. - Move proposal 134 forward.
  101. - putting port predictions in state file
  102. - if tor hasn't been used in a while it stops fetching consensus
  103. documents. Retain that state over restarts.
  104. Roger
  105. - Finish tor-doc-bridge.wml
  106. . Fix FAQ entry on setting up private Tor network
  107. - Review Karsten's hidden service diagrams
  108. - Roger should visit Internews DC sometime.
  109. - Did we actually apply Steven's dkimproxy patch?
  110. - Brainstorm about safe but effective ways for vidalia to
  111. auto-update its user's bridges via Tor in the background.
  112. Mike:
  113. - Roger wants to get an email every time there's a blog change,
  114. e.g. a comment. That way spam doesn't go undetected for weeks.
  115. - Or, maybe just disable linking from blog comments entirely?
  116. =======================================================================
  117. Bugs/issues for Tor 0.2.0.x:
  118. . we should have an off-by-default way for relays to dump geoip data to
  119. a file in their data directory, for measurement purposes.
  120. o Basic implementation
  121. N - Include probability-of-selection
  122. R d let bridges set relaybandwidthrate as low as 5kb
  123. R - bridge communities
  124. . spec
  125. . deploy
  126. - man page entries for Alternate*Authority config options
  127. Documentation for Tor 0.2.0.x:
  128. - Proposals:
  129. . 111: Prioritize local traffic over relayed.
  130. R - Merge into tor-spec.txt.
  131. - 113: mark as closed close.
  132. o document the "3/4 and 7/8" business in the clients fetching consensus
  133. documents timeline.
  134. R - then document the bridge user download timeline.
  135. - HOWTO for DNSPort. See tup's wiki page.
  136. . Document transport and natdport in a good HOWTO.
  137. - Quietly document NT Service options: revise (or create) FAQ entry
  138. =======================================================================
  139. For 0.2.1.2-alpha:
  140. R d bug: if we launch using bridges, and then stop using bridges, we
  141. still have our bridges in our entryguards section, and may use them.
  142. R d add an event to report geoip summaries to vidalia for bridge relays,
  143. so vidalia can say "recent activity (1-8 users) from sa".
  144. R - investigate: it looks like if the bridge authority is unreachable,
  145. we're not falling back on querying bridges directly?
  146. R - if "no running bridges known", an application request should make
  147. us retry all our bridges.
  148. R - get matt to make vidalia do a getinfo status/bootstrap-phase to
  149. get caught up after it connects.
  150. R d Setting DirPort when acting as bridge will give false Warnings
  151. For 0.2.1.x:
  152. - Proposals to do:
  153. o 110: avoid infinite-length circuits
  154. - 117: IPv6 Exits
  155. - Internal code support for ipv6:
  156. o Clone ipv6 functions (inet_ntop, inet_pton) where they don't exist.
  157. o Many address variables need to become tor_addr_t
  158. o addr in connection_t
  159. o n_addr in extend_info_t
  160. - Teach resolving code how to handle ipv6.
  161. . Teach exit policies about ipv6 (consider ipv4/ipv6 interaction!)
  162. o Use IPv6 in connect/connected/failed-exitpolicy cells
  163. o accept ipv6 from socks
  164. o Generate END_REASON_EXITPOLICY cells right
  165. . ... and parse them right
  166. . Generate new BEGIN cell types and parse them right
  167. - Detect availability of ipv6
  168. - Advertise availability of ipv6.
  169. - Geoip support, if only to add a zone called "ipv6"
  170. - 118: Listen on and advertise multiple ports:
  171. - Tor should be able to have a pool of outgoing IP addresses that it is
  172. able to rotate through. (maybe. Possible overlap with proposal 118.)
  173. - config option to publish what ports you listen on, beyond
  174. ORPort/DirPort. It should support ranges and bit prefixes (?) too.
  175. - Need to figure out the right format for routerinfo_t on this.
  176. - 121: Hidden service authentication
  177. R d 128: families of private bridges
  178. - 134: handle authority fragmentation.
  179. o 135: simplify configuration of private tor networks. Th
  180. - 140: Provide diffs betweeen consensuses
  181. - 147: Eliminate the need for v2 directories in generating v3 directories
  182. - 148: Stream end reasons from the client side should be uniform.
  183. - Maybe:
  184. - 145: Separate "suitable from a guard" from "suitable as a new guard"
  185. - 146: Adding new flag to reflect long-term stability
  186. - 149: Using data from NETINFO cells
  187. - Proposals to write:
  188. - Fix voting to handle bug 608 case when multiple servers get
  189. Named.
  190. R d Do we want to maintain our own set of entryguards that we use as
  191. next hop after the bridge?
  192. X Add an 'exit-address' line in the descriptor for servers that exit
  193. from something that isn't their published address.
  194. [I think tordnsel solved this. -RD]
  195. d Possibly: revise link protocol to allow big circuit IDs,
  196. variable-length cells, proposal-110 stuff, and versioned CREATES?
  197. o Eliminate use of v2 networkstatus documents in v3 authority
  198. decision-making.
  199. N . Draft proposal for GeoIP aggregation (see external constraints *)
  200. o Separate Guard flags for "pick this as a new guard" and "keep this
  201. as an existing guard". First investigate if we want this.
  202. . Figure out how to make good use of the fallback consensus file. Right
  203. now many of the addresses in the fallback consensus will be stale,
  204. so it will take dozens of minutes to bootstrap from it. This is a
  205. bad first Tor experience. But if we check the fallback consensus
  206. file *after* we fail to connect to any authorities, then it may
  207. still be valuable as a blocking-resistance step.
  208. o Write the proposal.
  209. - Patch our tor.spec rpm package so it knows where to put the fallback
  210. consensus file.
  211. d Something for bug 469, to limit connections per IP.
  212. . Put bandwidth weights in the networkstatus? So clients get weight
  213. their choices even before they have the descriptors; and so
  214. authorities can put in more accurate numbers in the future.
  215. d Fetch an updated geoip file from the directory authorities.
  216. - Tiny designs to write:
  217. . Better estimate of clock skew; has anonymity implications. Clients
  218. should estimate their skew as median of skew from servers over last
  219. N seconds, but for servers this is not so easy, since a server does
  220. not choose who it connects to.
  221. - Do TLS connection rotation more often than "once a week" in the
  222. extra-stable case.
  223. (One reason not to do it more often is because the old TLS conn
  224. probably has a circuit on it, and we don't really want to build up
  225. dozens of TCP connections to all the other extra-stable relays.)
  226. - If a relay publishes a new descriptor with a significantly lower
  227. uptime or with a new IP address, then we should consider its current
  228. "running" interval to have ended even if it hadn't yet failed its
  229. third reachability test. the interval ended when the new descriptor
  230. appeared, and a new interval began then too.
  231. - Use less RAM *
  232. - Optimize cell pool allocation.
  233. d Support (or just always use) jemalloc (if it helps)
  234. - mmap more files.
  235. - Look into pulling serverdescs off buffers as they arrive.
  236. - Use less bandwidth
  237. - Use if-modified-since to download consensuses
  238. - Handle multi-core cpus better
  239. - Split circuit AES across cores?
  240. - Split TLS across cores? This will be harder.
  241. - Use information from NETINFO cells
  242. - Don't extend a circuit over a noncanonical connection with
  243. mismatched address.
  244. - Learn our outgoing IP address from netinfo cells?
  245. - Learn skew from netinfo cells?
  246. - Testing
  247. - Better unit test coverage
  248. - Refactor unit tests into multiple files
  249. - Verify that write limits to linked connections work.
  250. - Use more mid-level and high-level libevent APIs
  251. - For dns?
  252. - For http?
  253. - For buffers?
  254. - Tool improvements:
  255. - Get IOCP patch into libevent *
  256. - Security improvements
  257. - make is-consensus-fresh-enough check way tighter.
  258. - If we haven't tried downloading a consensus for ages since we're tired,
  259. try getting a new one before we use old descriptors for a circuit.
  260. Related to bug 401.
  261. - Feature removals and deprecations:
  262. - Get rid of the v1 directory stuff (making, serving, and caching)
  263. - First verify that the caches won't flip out?
  264. - If they will, just stop the caches from caching for now
  265. - perhaps replace it with a "this is a tor server" stock webpage.
  266. - The v2dir flag isn't used for anything anymore, right? If so, dump it.
  267. - Even clients run rep_hist_load_mtbf_data(). Does this waste memory?
  268. Dump it?
  269. - Unless we start using ftime functions, dump them.
  270. - can we deprecate 'getinfo network-status'?
  271. - can we deprecate the FastFirstHopPK config option?
  272. - Can we deprecate controllers that don't use both features?
  273. - Dump most uint32_t addr functions.
  274. Nice to have for 0.2.1.x:
  275. - Proposals to write
  276. - steven's plan for replacing check.torproject.org with a built-in
  277. answer by tor itself.
  278. - Documentation
  279. P - Make documentation realize that location of system configuration file
  280. will depend on location of system defaults, and isn't always /etc/torrc.
  281. - Small controller features
  282. - A status event for when tor decides to stop fetching directory info
  283. if the client hasn't clicked recently: then make the onion change too.
  284. - Add a status event when new consensus arrives
  285. - Windows build
  286. P - Figure out why dll's compiled in mingw don't work right in WinXP.
  287. P - create a "make win32-bundle" for vidalia-privoxy-tor-torbutton bundle
  288. - Refactor bad code:
  289. - Refactor the HTTP logic so the functions aren't so large.
  290. - Refactor buf_read and buf_write to have sensible ways to return
  291. error codes after partial writes
  292. o Router_choose_random_node() has a big pile of args. make it "flags".
  293. - Streamline how we pick entry nodes: Make choose_random_entry() have
  294. less magic and less control logic.
  295. - Don't call time(NULL) so much; instead have a static time_t field
  296. that gets updated only a handful of times per second.
  297. - Move all status info out of routerinfo into local_routerstatus. Make
  298. "who can change what" in local_routerstatus explicit. Make
  299. local_routerstatus (or equivalent) subsume all places to go for "what
  300. router is this?"
  301. - deprecate router_digest_is_trusted_dir() in favor of
  302. router_get_trusteddirserver_by_digest()
  303. - Make Tor able to chroot itself
  304. o allow it to load an entire config file from control interface
  305. - document LOADCONF
  306. - log rotation (and FD passing) via control interface
  307. - chroot yourself, including inhibit trying to read config file
  308. and reopen logs, unless they are under datadir.
  309. - Should be trivial:
  310. - Base relative control socket paths (and other stuff in torrc) on datadir.
  311. - Tor logs the libevent version on startup, for debugging purposes.
  312. This is great. But it does this before configuring the logs, so
  313. it only goes to stdout and is then lost.
  314. - Make TrackHostExits expire TrackHostExitsExpire seconds after their
  315. *last* use, not their *first* use.
  316. - enforce a lower limit on MaxCircuitDirtiness and CircuitBuildTimeout.
  317. - Make 'safelogging' extend to info-level logs too.
  318. - don't do dns hijacking tests if we're reject *:* exit policy?
  319. (deferred until 0.1.1.x is less common)
  320. - More consistent error checking in router_parse_entry_from_string().
  321. I can say "banana" as my bandwidthcapacity, and it won't even squeak.
  322. - Interface for letting SOAT modify flags that authorities assign.
  323. (How to keep the authority from clobbering them afterwards?