TODO.021 16 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386
  1. Legend:
  2. SPEC!! - Not specified
  3. SPEC - Spec not finalized
  4. N - nick claims
  5. R - arma claims
  6. P - phobos claims
  7. S - Steven claims
  8. E - Matt claims
  9. M - Mike claims
  10. J - Jeff claims
  11. I - ioerror claims
  12. W - weasel claims
  13. K - Karsten claims
  14. - Not done
  15. * Top priority
  16. . Partially done
  17. o Done
  18. d Deferrable
  19. D Deferred
  20. X Abandoned
  21. =======================================================================
  22. Things Roger would be excited to see:
  23. Nick
  24. * Look at Roger's proposal 141 discussions on or-dev, and help us
  25. decide how to proceed.
  26. . Tors start believing the contents of NETINFO cells.
  27. - respond to Steven's red-team TLS testing (a.k.a, look at a packet
  28. dump and compare)
  29. Matt
  30. - Fit Vidalia in 640x480 again.
  31. - Vidalia should avoid stomping on your custom exit policy lines
  32. just because you click on 'save' for a totally different config thing.
  33. - How much space do we save in TBB by stripping symbols from Vidalia
  34. first? Good idea or crazy idea?
  35. (phobos adds you save about 12MB total across all exes by stripping
  36. them) In fact, tbb-1.19 is stripped exes.
  37. ioerror
  38. * weather.torproject.org should go live.
  39. - Keep advocating new Tor servers and working with orgs like Mozilla
  40. to let them like Tor.
  41. - Find out what happened to the buildbot and get it back up:
  42. http://tor-buildbot.freehaven.net:8010/
  43. - Learn about locking memory pages that have sensitive content. Get
  44. that started in Tor.
  45. - Translation portal
  46. - Vidalia html help files
  47. - should we i18nize polipo's error messages too?
  48. - how to get our diagrams translated, and how to get our screenshots
  49. from the right language?
  50. - Some of our translated wml files are very old -- so old that they
  51. are harmful to leave in place. We need some sort of way to notice
  52. this and disable them.
  53. Steven
  54. - Move proposal 131 or equivalent forward.
  55. - Keep bugging us about exploits on the .exit notation.
  56. - Mike's question #3 on https://www.torproject.org/volunteer#Research
  57. - Worthwhile shipping TBB with some local html help files that come
  58. as bookmarks?
  59. Andrew
  60. Weasel
  61. - Figure out how to make Vidalia and Tor play nicely on Debian, make
  62. the necessary modifications, and make some Vidalia debs that pass
  63. muster.
  64. - Fix bug 393.
  65. - Get oftc to switch to Tor dns bulk exitlist. Or tell us why it's
  66. not suitable yet.
  67. - Move proposal 134 forward.
  68. - putting port predictions in state file
  69. - if tor hasn't been used in a while it stops fetching consensus
  70. documents. Retain that state over restarts.
  71. Roger
  72. - Finish tor-doc-bridge.wml
  73. . Fix FAQ entry on setting up private Tor network
  74. - Did we actually apply Steven's dkimproxy patch?
  75. - Brainstorm about safe but effective ways for vidalia to
  76. auto-update its user's bridges via Tor in the background.
  77. - it doesn't count as successfully opening a circuit if it's not
  78. an exit circuit.
  79. Mike:
  80. - Roger wants to get an email every time there's a blog change,
  81. e.g. a comment. That way spam doesn't go undetected for weeks.
  82. - Or, maybe just disable linking from blog comments entirely?
  83. (phobos mitigates this by checking it a few times a week)
  84. =======================================================================
  85. Bugs/issues for Tor 0.2.0.x:
  86. . we should have an off-by-default way for relays to dump geoip data to
  87. a file in their data directory, for measurement purposes.
  88. o Basic implementation
  89. N - Include probability-of-selection
  90. R d let bridges set relaybandwidthrate as low as 5kb
  91. Documentation for Tor 0.2.0.x:
  92. o Proposals:
  93. o 111: Prioritize local traffic over relayed.
  94. o 113: mark as closed close.
  95. o document the "3/4 and 7/8" business in the clients fetching consensus
  96. documents timeline.
  97. R - then document the bridge user download timeline.
  98. - HOWTO for DNSPort. See tup's wiki page.
  99. . Document transport and natdport in a good HOWTO.
  100. - Quietly document NT Service options: revise (or create) FAQ entry
  101. =======================================================================
  102. For 0.2.1.x-alpha:
  103. R d bug: if we launch using bridges, and then stop using bridges, we
  104. still have our bridges in our entryguards section, and may use them.
  105. o add an event to report geoip summaries to vidalia for bridge relays,
  106. so vidalia can say "recent activity (1-8 users) from sa".
  107. R - investigate: it looks like if the bridge authority is unreachable,
  108. we're not falling back on querying bridges directly?
  109. o if "no running bridges known", an application request should make
  110. us retry all our bridges.
  111. For 0.2.1.x:
  112. - Proposals to do:
  113. o 110: avoid infinite-length circuits
  114. * Figure out the right value for max RELAY_EARLY cells (Bug 878)
  115. - 117: IPv6 Exits
  116. - Internal code support for ipv6:
  117. o Clone ipv6 functions (inet_ntop, inet_pton) where they don't exist.
  118. o Many address variables need to become tor_addr_t
  119. o addr in connection_t
  120. o n_addr in extend_info_t
  121. - Teach resolving code how to handle ipv6.
  122. . Teach exit policies about ipv6 (consider ipv4/ipv6 interaction!)
  123. o Use IPv6 in connect/connected/failed-exitpolicy cells
  124. o accept ipv6 from socks
  125. o Generate END_REASON_EXITPOLICY cells right
  126. . ... and parse them right
  127. . Generate new BEGIN cell types and parse them right
  128. - Detect availability of ipv6
  129. - Advertise availability of ipv6.
  130. - Geoip support, if only to add a zone called "ipv6"
  131. K . 121: Hidden service authentication:
  132. - missing: delayed descriptor publication for 'stealth' mode.
  133. o 128: families of private bridges
  134. o 135: simplify configuration of private tor networks.
  135. K - 143: Improvements of Distributed Hidden Service Descriptor Storage:
  136. only easy parts for 0.2.1.x, defer complex ones to 0.2.2.x.
  137. o 148: Stream end reasons from the client side should be uniform.
  138. K o 155: Four Improvements of Hidden Service Performance
  139. - 145: Separate "suitable from a guard" from "suitable as a new guard"
  140. - 146: Adding new flag to reflect long-term stability
  141. - 149: Using data from NETINFO cells
  142. o Don't extend a circuit over a noncanonical connection with
  143. mismatched address.
  144. o Apply rovv's bugfixes wrt preferring canonical connections.
  145. o Make sure that having a non-canonical connection doesn't count
  146. as _having_ a connection for the purpose of connecting to others,
  147. and that when no canonical connection exists, we make one.
  148. - Learn our outgoing IP address from netinfo cells?
  149. - Learn skew from netinfo cells?
  150. o 157: Make certificate downloads specific.
  151. - Proposals to write:
  152. - Fix voting to handle bug 608 case when multiple servers get
  153. Named.
  154. N . Draft proposal for GeoIP aggregation (see external constraints *)
  155. . Figure out how to make good use of the fallback consensus file. Right
  156. now many of the addresses in the fallback consensus will be stale,
  157. so it will take dozens of minutes to bootstrap from it. This is a
  158. bad first Tor experience. But if we check the fallback consensus
  159. file *after* we fail to connect to any authorities, then it may
  160. still be valuable as a blocking-resistance step.
  161. o Write the proposal.
  162. - Patch our tor.spec rpm package so it knows where to put the fallback
  163. consensus file.
  164. . Put bandwidth weights in the networkstatus? So clients get weight
  165. their choices even before they have the descriptors; and so
  166. authorities can put in more accurate numbers in the future.
  167. - Spec compliance:
  168. * Make sure that clients could do the new handshake without sending any
  169. certs, if they wanted.
  170. - Tiny designs to write:
  171. - If a relay publishes a new descriptor with a significantly lower
  172. uptime or with a new IP address, then we should consider its current
  173. "running" interval to have ended even if it hadn't yet failed its
  174. third reachability test. the interval ended when the new descriptor
  175. appeared, and a new interval began then too.
  176. - Authority improvements:
  177. R - authorities should initiate a reachability test upon first
  178. glimpsing a new descriptor.
  179. - Use less bandwidth
  180. - Use if-modified-since to download consensuses
  181. - Testing
  182. - Better unit test coverage
  183. - Verify that write limits to linked connections work.
  184. - Security improvements
  185. - make is-consensus-fresh-enough check tighter.
  186. - If we haven't tried downloading a consensus for ages since we're tired,
  187. try getting a new one before we use old descriptors for a circuit.
  188. Related to bug 401. [What does "since we're tired" mean? -RD]
  189. [I don't know. -NM]
  190. - Feature removals and deprecations:
  191. - Get rid of the v1 directory stuff (making, serving, and caching)
  192. . First verify that the caches won't flip out?
  193. o If they will, just stop the caches from caching for now
  194. . perhaps replace it with a "this is a tor server" stock webpage.
  195. - Get the debs to set DirPortFrontPage in the default.
  196. - Decide how to handle DirPortFrontPage files with image links.
  197. - Can we deprecate controllers that don't use both features?
  198. - Both TorK and Vidalia use VERBOSE_NAMES.
  199. - TorK uses EXTENDED_EVENTS. Vidalia does not. (As of 9 Dec.)
  200. - Matt is checking whether Vidalia would break if we started to use
  201. EXTENDED_EVENTS by default. He says no.
  202. External tool improvements:
  203. - Get IOCP patches into libevent
  204. Nice to have for 0.2.1.x:
  205. - Proposals, time permitting
  206. - 134: handle authority fragmentation.
  207. - 140: Provide diffs betweeen consensuses
  208. - Handle multi-core cpus better
  209. - Split circuit AES across cores
  210. - Split cell_queue_t into a new structure with a processed subqueue,
  211. an unprocessed subqueue, and a symmetric key.
  212. - Write a function to pull cells from the unprocessed subqueue,
  213. en/decrypt them, and place them on the processed subqueue.
  214. - When a cell is added to a queue that previously had no
  215. unprocessed cells, put that queue into a set of queues that
  216. need to be processed. When the last cell is processed in a
  217. queue, remove it from the set of queues that need to be
  218. processed.
  219. - Worker code to process queues in round-robin fashion.
  220. - Think about how to be fair to differet circuits _and_ about to get
  221. CPU-affinity, if that matters.
  222. - When a cell is processed and placed onto a processed subqueue
  223. that was previously empty, _and_ the or_conn output buffer
  224. that the queue is targetting is empty, stick the buffer onto a
  225. list of buffers that need attention and notify the main
  226. thread if it was not already on the list.
  227. - When the main thread gets notified, it pumps those buffers.
  228. (i.e., it puts cells onto them from some of their circuits).
  229. - To free a queue that is not currently processing, grab its lock
  230. and free it.
  231. - To free a queue that _is_ processing, .... ?
  232. - Documentation
  233. P - Make documentation realize that location of system configuration file
  234. will depend on location of system defaults, and isn't always /etc/torrc.
  235. - Small controller features
  236. - A status event for when tor decides to stop fetching directory info
  237. if the client hasn't clicked recently: then make the onion change too.
  238. o Add a status event when new consensus arrives
  239. - Windows build
  240. P - create a "make win32-bundle" for vidalia-privoxy-tor-torbutton bundle
  241. - Is this obsolete with msi bundle coming soon asks phobos
  242. - Refactor bad code:
  243. - connection_or_get_by_identity_digest() and connection_good_enough_for
  244. _extend() could be merged into a smarter variant, perhaps.
  245. - Refactor the HTTP logic so the functions aren't so large.
  246. - Refactor buf_read and buf_write to have sensible ways to return
  247. error codes after partial writes
  248. - deprecate router_digest_is_trusted_dir() in favor of
  249. router_get_trusteddirserver_by_digest()
  250. - Should be trivial
  251. - Tor logs the libevent version on startup, for debugging purposes.
  252. This is great. But it does this before configuring the logs, so
  253. it only goes to stdout and is then lost.
  254. (phobos asks, is this still the case? because it shows up in my
  255. logs)
  256. - Deprecations
  257. - Even clients run rep_hist_load_mtbf_data(). This doesn't waste memory
  258. unless they had previously been non-clients collecting MTBF data.
  259. Dump it anyway?
  260. - Unless we start using ftime functions, dump them.
  261. - can we deprecate the FastFirstHopPK config option?
  262. - The v2dir flag isn't used for anything anymore, right? If so, dump it.
  263. - can we deprecate 'getinfo network-status'?
  264. - Dump most uint32_t addr functions.
  265. - do the part of the "abandon .exit" proposal that involves isolating
  266. circuits which have used a .exit stream from those that haven't
  267. Defer:
  268. - Proposals
  269. - 118: Listen on and advertise multiple ports:
  270. - Tor should be able to have a pool of outgoing IP addresses that it is
  271. able to rotate through. (maybe. Possible overlap with proposal 118.)
  272. - config option to publish what ports you listen on, beyond
  273. ORPort/DirPort. It should support ranges and bit prefixes (?) too.
  274. - Need to figure out the right format for routerinfo_t on this.
  275. - 147: Eliminate the need for v2 directories in generating v3 directories
  276. - Proposals to write.
  277. d Something for bug 469, to limit connections per IP.
  278. d Do we want to maintain our own set of entryguards that we use as
  279. next hop after the bridge?
  280. d Possibly: revise link protocol to allow big circuit IDs,
  281. variable-length cells, proposal-110 stuff, and versioned CREATES?
  282. d Fetch an updated geoip file from the directory authorities.
  283. R - bridge communities (revive proposal 128)
  284. . spec
  285. . deploy
  286. - man page entries for Alternate*Authority config options
  287. - Tiny designs to write
  288. - Better estimate of clock skew; has anonymity implications. Clients
  289. should estimate their skew as median of skew from servers over last
  290. N seconds, but for servers this is not so easy, since a server does
  291. not choose who it connects to.
  292. - Do TLS connection rotation more often than "once a week" in the
  293. extra-stable case.
  294. (One reason not to do it more often is because the old TLS conn
  295. probably has a circuit on it, and we don't really want to build up
  296. dozens of TCP connections to all the other extra-stable relays.)
  297. - Use less RAM
  298. - Optimize cell pool allocation.
  299. - Support (or just always use) jemalloc (if it helps)
  300. - mmap more files.
  301. - Pull serverdescs off buffers as they arrive.
  302. - Allocate routerstatus_t objects on a per-networkstatus memchunk.
  303. - Split TLS across multiple cores
  304. - "In the future, we should migrate to LOCAL_APPDATA entirely."
  305. - Use more mid-level and high-level libevent APIs
  306. - For dns?
  307. - For http?
  308. - For buffers?
  309. - Proposals to write
  310. - steven's plan for replacing check.torproject.org with a built-in
  311. answer by tor itself.
  312. - Refactor bad code:
  313. - Streamline how we pick entry nodes: Make choose_random_entry() have
  314. less magic and less control logic.
  315. - Move all status info out of routerinfo into local_routerstatus. Make
  316. "who can change what" in local_routerstatus explicit. Make
  317. local_routerstatus (or equivalent) subsume all places to go for "what
  318. router is this?"
  319. o Don't call time(NULL) so much; instead have a static time_t field
  320. that gets updated only a handful of times per second.
  321. - Refactor unit tests into multiple files
  322. - Make Tor able to chroot itself
  323. o allow it to load an entire config file from control interface
  324. - document LOADCONF
  325. - log rotation (and FD passing) via control interface
  326. - chroot yourself, including inhibit trying to read config file
  327. and reopen logs, unless they are under datadir.
  328. - Should be trivial:
  329. - Base relative control socket paths (and other stuff in torrc) on datadir.
  330. o enforce a lower limit on MaxCircuitDirtiness and CircuitBuildTimeout.
  331. - Make 'safelogging' extend to info-level logs too.
  332. - don't do dns hijacking tests if we're reject *:* exit policy?
  333. (deferred until 0.1.1.x is less common)
  334. - More consistent error checking in router_parse_entry_from_string().
  335. I can say "banana" as my bandwidthcapacity, and it won't even squeak.
  336. d Interface for letting SOAT modify flags that authorities assign.
  337. (How to keep the authority from clobbering them afterwards?