From a60680c2267706db081699445abcbcde4a81c526 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Mon, 17 Dec 2012 22:26:05 -0500 Subject: [PATCH] Remove the obsolete doc/TODO.* files Closes bug #7730. --- doc/TODO | 12 +- doc/TODO.021 | 386 ---------------------------------------------- doc/TODO.022 | 92 ----------- doc/TODO.external | 4 - doc/TODO.future | 330 --------------------------------------- 5 files changed, 2 insertions(+), 822 deletions(-) delete mode 100644 doc/TODO.021 delete mode 100644 doc/TODO.022 delete mode 100644 doc/TODO.external delete mode 100644 doc/TODO.future diff --git a/doc/TODO b/doc/TODO index 194d6507bc..7e547496e4 100644 --- a/doc/TODO +++ b/doc/TODO @@ -1,11 +1,3 @@ -We've split out our TODO into three files: - -TODO.02x is the list of items we're planning to get done in the next -stable release. - -TODO.external lives in svn under /projects/todo/. It's the list of -external constraints and deliverables that we all need to keep in mind. - -TODO.future is the list of other items we plan to get to in later releases. - +We no longer track our TODO lists in git. To see open Tor tasks, visit +our bugtracker and wiki at trac.torproject.org. diff --git a/doc/TODO.021 b/doc/TODO.021 deleted file mode 100644 index 37c5b9845b..0000000000 --- a/doc/TODO.021 +++ /dev/null @@ -1,386 +0,0 @@ -Legend: -SPEC!! - Not specified -SPEC - Spec not finalized -N - nick claims -R - arma claims -P - phobos claims -S - Steven claims -E - Matt claims -M - Mike claims -J - Jeff claims -I - ioerror claims -W - weasel claims -K - Karsten claims - - Not done - * Top priority - . Partially done - o Done - d Deferrable - D Deferred - X Abandoned - -======================================================================= - -Things Roger would be excited to see: - -Nick - * Look at Roger's proposal 141 discussions on or-dev, and help us - decide how to proceed. - . Tors start believing the contents of NETINFO cells. - - respond to Steven's red-team TLS testing (a.k.a, look at a packet - dump and compare) - -Matt - - Fit Vidalia in 640x480 again. - - Vidalia should avoid stomping on your custom exit policy lines - just because you click on 'save' for a totally different config thing. - - How much space do we save in TBB by stripping symbols from Vidalia - first? Good idea or crazy idea? - (phobos adds you save about 12MB total across all exes by stripping - them) In fact, tbb-1.19 is stripped exes. - -ioerror - * weather.torproject.org should go live. - - Keep advocating new Tor servers and working with orgs like Mozilla - to let them like Tor. - - Find out what happened to the buildbot and get it back up: - http://tor-buildbot.freehaven.net:8010/ - - Learn about locking memory pages that have sensitive content. Get - that started in Tor. - - Translation portal - - Vidalia html help files - - should we i18nize polipo's error messages too? - - how to get our diagrams translated, and how to get our screenshots - from the right language? - - Some of our translated wml files are very old -- so old that they - are harmful to leave in place. We need some sort of way to notice - this and disable them. - -Steven - - Move proposal 131 or equivalent forward. - - Keep bugging us about exploits on the .exit notation. - - Mike's question #3 on https://www.torproject.org/volunteer#Research - - Worthwhile shipping TBB with some local html help files that come - as bookmarks? - -Andrew - -Weasel - - Figure out how to make Vidalia and Tor play nicely on Debian, make - the necessary modifications, and make some Vidalia debs that pass - muster. - - Fix bug 393. - - Get oftc to switch to Tor dns bulk exitlist. Or tell us why it's - not suitable yet. - - Move proposal 134 forward. - - putting port predictions in state file - - if tor hasn't been used in a while it stops fetching consensus - documents. Retain that state over restarts. - -Roger - - Finish tor-doc-bridge.wml - . Fix FAQ entry on setting up private Tor network - - Did we actually apply Steven's dkimproxy patch? - - Brainstorm about safe but effective ways for vidalia to - auto-update its user's bridges via Tor in the background. - - it doesn't count as successfully opening a circuit if it's not - an exit circuit. - -Mike: - - Roger wants to get an email every time there's a blog change, - e.g. a comment. That way spam doesn't go undetected for weeks. - - Or, maybe just disable linking from blog comments entirely? - (phobos mitigates this by checking it a few times a week) - -======================================================================= - -Bugs/issues for Tor 0.2.0.x: - . we should have an off-by-default way for relays to dump geoip data to - a file in their data directory, for measurement purposes. - o Basic implementation -N - Include probability-of-selection -R d let bridges set relaybandwidthrate as low as 5kb - -Documentation for Tor 0.2.0.x: - o Proposals: - o 111: Prioritize local traffic over relayed. - o 113: mark as closed close. - o document the "3/4 and 7/8" business in the clients fetching consensus - documents timeline. -R - then document the bridge user download timeline. - - HOWTO for DNSPort. See tup's wiki page. - . Document transport and natdport in a good HOWTO. - - Quietly document NT Service options: revise (or create) FAQ entry - -======================================================================= - -For 0.2.1.x-alpha: -R d bug: if we launch using bridges, and then stop using bridges, we - still have our bridges in our entryguards section, and may use them. - o add an event to report geoip summaries to vidalia for bridge relays, - so vidalia can say "recent activity (1-8 users) from sa". -R - investigate: it looks like if the bridge authority is unreachable, - we're not falling back on querying bridges directly? - o if "no running bridges known", an application request should make - us retry all our bridges. - -For 0.2.1.x: - - Proposals to do: - o 110: avoid infinite-length circuits - * Figure out the right value for max RELAY_EARLY cells (Bug 878) - - 117: IPv6 Exits - - Internal code support for ipv6: - o Clone ipv6 functions (inet_ntop, inet_pton) where they don't exist. - o Many address variables need to become tor_addr_t - o addr in connection_t - o n_addr in extend_info_t - - Teach resolving code how to handle ipv6. - . Teach exit policies about ipv6 (consider ipv4/ipv6 interaction!) - o Use IPv6 in connect/connected/failed-exitpolicy cells - o accept ipv6 from socks - o Generate END_REASON_EXITPOLICY cells right - . ... and parse them right - . Generate new BEGIN cell types and parse them right - - Detect availability of ipv6 - - Advertise availability of ipv6. - - Geoip support, if only to add a zone called "ipv6" - -K . 121: Hidden service authentication: - - missing: delayed descriptor publication for 'stealth' mode. - o 128: families of private bridges - o 135: simplify configuration of private tor networks. -K - 143: Improvements of Distributed Hidden Service Descriptor Storage: - only easy parts for 0.2.1.x, defer complex ones to 0.2.2.x. - o 148: Stream end reasons from the client side should be uniform. -K o 155: Four Improvements of Hidden Service Performance - - 145: Separate "suitable from a guard" from "suitable as a new guard" - - 146: Adding new flag to reflect long-term stability - - 149: Using data from NETINFO cells - o Don't extend a circuit over a noncanonical connection with - mismatched address. - o Apply rovv's bugfixes wrt preferring canonical connections. - o Make sure that having a non-canonical connection doesn't count - as _having_ a connection for the purpose of connecting to others, - and that when no canonical connection exists, we make one. - - Learn our outgoing IP address from netinfo cells? - - Learn skew from netinfo cells? - o 157: Make certificate downloads specific. - - - Proposals to write: - - Fix voting to handle bug 608 case when multiple servers get - Named. -N . Draft proposal for GeoIP aggregation (see external constraints *) - . Figure out how to make good use of the fallback consensus file. Right - now many of the addresses in the fallback consensus will be stale, - so it will take dozens of minutes to bootstrap from it. This is a - bad first Tor experience. But if we check the fallback consensus - file *after* we fail to connect to any authorities, then it may - still be valuable as a blocking-resistance step. - o Write the proposal. - - Patch our tor.spec rpm package so it knows where to put the fallback - consensus file. - . Put bandwidth weights in the networkstatus? So clients get weight - their choices even before they have the descriptors; and so - authorities can put in more accurate numbers in the future. - - - Spec compliance: - * Make sure that clients could do the new handshake without sending any - certs, if they wanted. - - - Tiny designs to write: - - If a relay publishes a new descriptor with a significantly lower - uptime or with a new IP address, then we should consider its current - "running" interval to have ended even if it hadn't yet failed its - third reachability test. the interval ended when the new descriptor - appeared, and a new interval began then too. - - - Authority improvements: -R - authorities should initiate a reachability test upon first - glimpsing a new descriptor. - - - Use less bandwidth - - Use if-modified-since to download consensuses - - - Testing - - Better unit test coverage - - Verify that write limits to linked connections work. - - - Security improvements - - make is-consensus-fresh-enough check tighter. - - If we haven't tried downloading a consensus for ages since we're tired, - try getting a new one before we use old descriptors for a circuit. - Related to bug 401. [What does "since we're tired" mean? -RD] - [I don't know. -NM] - - - Feature removals and deprecations: - - Get rid of the v1 directory stuff (making, serving, and caching) - . First verify that the caches won't flip out? - o If they will, just stop the caches from caching for now - . perhaps replace it with a "this is a tor server" stock webpage. - - Get the debs to set DirPortFrontPage in the default. - - Decide how to handle DirPortFrontPage files with image links. - - Can we deprecate controllers that don't use both features? - - Both TorK and Vidalia use VERBOSE_NAMES. - - TorK uses EXTENDED_EVENTS. Vidalia does not. (As of 9 Dec.) - - Matt is checking whether Vidalia would break if we started to use - EXTENDED_EVENTS by default. He says no. - -External tool improvements: - - Get IOCP patches into libevent - -Nice to have for 0.2.1.x: - - Proposals, time permitting - - 134: handle authority fragmentation. - - 140: Provide diffs betweeen consensuses - - - Handle multi-core cpus better - - Split circuit AES across cores - - Split cell_queue_t into a new structure with a processed subqueue, - an unprocessed subqueue, and a symmetric key. - - Write a function to pull cells from the unprocessed subqueue, - en/decrypt them, and place them on the processed subqueue. - - When a cell is added to a queue that previously had no - unprocessed cells, put that queue into a set of queues that - need to be processed. When the last cell is processed in a - queue, remove it from the set of queues that need to be - processed. - - Worker code to process queues in round-robin fashion. - - Think about how to be fair to differet circuits _and_ about to get - CPU-affinity, if that matters. - - When a cell is processed and placed onto a processed subqueue - that was previously empty, _and_ the or_conn output buffer - that the queue is targetting is empty, stick the buffer onto a - list of buffers that need attention and notify the main - thread if it was not already on the list. - - When the main thread gets notified, it pumps those buffers. - (i.e., it puts cells onto them from some of their circuits). - - To free a queue that is not currently processing, grab its lock - and free it. - - To free a queue that _is_ processing, .... ? - - - Documentation -P - Make documentation realize that location of system configuration file - will depend on location of system defaults, and isn't always /etc/torrc. - - - Small controller features - - A status event for when tor decides to stop fetching directory info - if the client hasn't clicked recently: then make the onion change too. - o Add a status event when new consensus arrives - - - Windows build -P - create a "make win32-bundle" for vidalia-privoxy-tor-torbutton bundle - - Is this obsolete with msi bundle coming soon asks phobos - - - Refactor bad code: - - connection_or_get_by_identity_digest() and connection_good_enough_for - _extend() could be merged into a smarter variant, perhaps. - - Refactor the HTTP logic so the functions aren't so large. - - Refactor buf_read and buf_write to have sensible ways to return - error codes after partial writes - - deprecate router_digest_is_trusted_dir() in favor of - router_get_trusteddirserver_by_digest() - - - Should be trivial - - Tor logs the libevent version on startup, for debugging purposes. - This is great. But it does this before configuring the logs, so - it only goes to stdout and is then lost. - (phobos asks, is this still the case? because it shows up in my - logs) - - - Deprecations - - Even clients run rep_hist_load_mtbf_data(). This doesn't waste memory - unless they had previously been non-clients collecting MTBF data. - Dump it anyway? - - Unless we start using ftime functions, dump them. - - can we deprecate the FastFirstHopPK config option? - - The v2dir flag isn't used for anything anymore, right? If so, dump it. - - can we deprecate 'getinfo network-status'? - - Dump most uint32_t addr functions. - - - do the part of the "abandon .exit" proposal that involves isolating - circuits which have used a .exit stream from those that haven't - -Defer: - - Proposals - - 118: Listen on and advertise multiple ports: - - Tor should be able to have a pool of outgoing IP addresses that it is - able to rotate through. (maybe. Possible overlap with proposal 118.) - - config option to publish what ports you listen on, beyond - ORPort/DirPort. It should support ranges and bit prefixes (?) too. - - Need to figure out the right format for routerinfo_t on this. - - 147: Eliminate the need for v2 directories in generating v3 directories - - - Proposals to write. - d Something for bug 469, to limit connections per IP. - d Do we want to maintain our own set of entryguards that we use as - next hop after the bridge? - d Possibly: revise link protocol to allow big circuit IDs, - variable-length cells, proposal-110 stuff, and versioned CREATES? - d Fetch an updated geoip file from the directory authorities. -R - bridge communities (revive proposal 128) - . spec - . deploy - - man page entries for Alternate*Authority config options - - - Tiny designs to write - - Better estimate of clock skew; has anonymity implications. Clients - should estimate their skew as median of skew from servers over last - N seconds, but for servers this is not so easy, since a server does - not choose who it connects to. - - Do TLS connection rotation more often than "once a week" in the - extra-stable case. - (One reason not to do it more often is because the old TLS conn - probably has a circuit on it, and we don't really want to build up - dozens of TCP connections to all the other extra-stable relays.) - - - - Use less RAM - - Optimize cell pool allocation. - - Support (or just always use) jemalloc (if it helps) - - mmap more files. - - Pull serverdescs off buffers as they arrive. - - Allocate routerstatus_t objects on a per-networkstatus memchunk. - - - Split TLS across multiple cores - - - "In the future, we should migrate to LOCAL_APPDATA entirely." - - - Use more mid-level and high-level libevent APIs - - For dns? - - For http? - - For buffers? - - - Proposals to write - - steven's plan for replacing check.torproject.org with a built-in - answer by tor itself. - - - Refactor bad code: - - Streamline how we pick entry nodes: Make choose_random_entry() have - less magic and less control logic. - - Move all status info out of routerinfo into local_routerstatus. Make - "who can change what" in local_routerstatus explicit. Make - local_routerstatus (or equivalent) subsume all places to go for "what - router is this?" - o Don't call time(NULL) so much; instead have a static time_t field - that gets updated only a handful of times per second. - - Refactor unit tests into multiple files - - - Make Tor able to chroot itself - o allow it to load an entire config file from control interface - - document LOADCONF - - log rotation (and FD passing) via control interface - - chroot yourself, including inhibit trying to read config file - and reopen logs, unless they are under datadir. - - - Should be trivial: - - Base relative control socket paths (and other stuff in torrc) on datadir. - o enforce a lower limit on MaxCircuitDirtiness and CircuitBuildTimeout. - - Make 'safelogging' extend to info-level logs too. - - don't do dns hijacking tests if we're reject *:* exit policy? - (deferred until 0.1.1.x is less common) - - More consistent error checking in router_parse_entry_from_string(). - I can say "banana" as my bandwidthcapacity, and it won't even squeak. - - d Interface for letting SOAT modify flags that authorities assign. - (How to keep the authority from clobbering them afterwards? - diff --git a/doc/TODO.022 b/doc/TODO.022 deleted file mode 100644 index d83ed6e671..0000000000 --- a/doc/TODO.022 +++ /dev/null @@ -1,92 +0,0 @@ -Nick's initial priorities for Tor 0.2.2: - -NOTE 1: I'm not looking at fiddly little stuff from TODO.021 yet. We - can do a step where we triage the nice-to-have issues. - -NOTE 2: It's easy to list stuff like this with no time estimates and - no target dates. I think we should pick a target date for - 0.2.2, figure out how long the stuff we want will take, and - triage accordingly, or vice versa. - -- Performance, mostly protocol-neutral. - - o Revise how we do bandwidth limiting and round-robining between - circuits on a connection. - - . Revise how we do bandwidth limiting and round-robining between - connections. - - - Better flow-control to avoid filling buffers on routers. - - - Figure out good ways to instrument Tor internals so we can tell - how well our bandwidth and flow-control stuff is actually working. - - What ports eat the bandwidth? - - How full do queues get? - - How much latency do queues get? - - - Rate limit at clients: - - Give clients an upper bound on how much they're willing to use - the network if they're not relaying? - - ... or group client circuits by IP at the server and rate-limit - like that. - - - Use if-modified-since to download consensuses - - -- Other features - - Proposals to implement: - - 146: reflect long-term stability in consensuses - - 147: Stop using v2 directories to generate v3 votes. - - Start pinging as soon as we learn about a relay, not on a - 22-minute cycle. Prioritize new and volatile relays for - testing. - - - Proposals to improve and implement - - 158: microdescriptors - o Revise proposal - - Implement - - - Proposals to improve and implement if not broken - D IPv6 support. (Parts of 117, but figure out how to handle DNS - requests.) - - 140: Directory diffs - - Need a decent simple C diff implementation. - - Need a decent simple C ed patch implementation. - - 149: learn info from netinfo cells. - o Start discussion - - Revise proposal based on discussion. - X 134: handle authority fragmentation (Needs more analysis) - - 165: Easy migration for voting authority sets - - 163: Detect client-status better - o Write proposal - - Possibly implement, depending on discussion. - - 164: Have authorities report relay and voting status better: make it - easy to answer, "Why is my server not listed/not Guard/not - Running/etc" - o Write proposal - - Possibly implement, depending on discussion - - 162: Have consensuses come in multiple "flavours". - o Write proposal - - Possibly implement, depending on discussion. - - - Needs a proposal, or at least some design - - Weaken the requirements for being a Guard, based on K's - measurements. -K - Finish measurements -K? - Write proposal - - Adaptive timeouts for giving up on circuits and streams. -M - Revise proposal 151 - - Downweight guards more sensibly: be more forgiving about using - Guard nodes as non-first-hop. - - Write proposal. - - Lagged weight updates in consensuses: don't just move abruptly. -M? - Write proposal - d Don't kill a circuit on the first failed extend. - -- Installers - - Switch to MSI on win32 - - Use Thandy, perhaps? - -o Deprecations - o Make .exit safe, or make it off-by-default. - diff --git a/doc/TODO.external b/doc/TODO.external deleted file mode 100644 index 2e7e536efc..0000000000 --- a/doc/TODO.external +++ /dev/null @@ -1,4 +0,0 @@ - -[This file moved to svn in /projects/todo/. More people can edit -it more easily there. -RD] - diff --git a/doc/TODO.future b/doc/TODO.future deleted file mode 100644 index 85e07aa921..0000000000 --- a/doc/TODO.future +++ /dev/null @@ -1,330 +0,0 @@ -Legend: -SPEC!! - Not specified -SPEC - Spec not finalized -N - nick claims -R - arma claims -P - phobos claims -S - Steven claims -E - Matt claims -M - Mike claims -J - Jeff claims -I - ioerror claims -W - weasel claims -K - Karsten claims - - Not done - * Top priority - . Partially done - o Done - d Deferrable - D Deferred - X Abandoned - -======================================================================= - -Later, unless people want to implement them now: - - Actually use SSL_shutdown to close our TLS connections. - - Include "v" line in networkstatus getinfo values. - [Nick: bridge authorities output a networkstatus that is missing - version numbers. This is inconvenient if we want to make sure - bridgedb gives out bridges with certain characteristics. -RD] - [Okay. Is this a separate item, or is it the same issue as the lack of - a "v" line in response to the controller GETINFO command? -NM] - - MAYBE kill stalled circuits rather than stalled connections. This is - possible thanks to cell queues, but we need to consider the anonymity - implications. - - Make resolves no longer use edge_connection_t unless they are actually - _on_ a socks connection: have edge_connection_t and (say) - dns_request_t both extend an edge_stream_t, and have p_streams and - n_streams both be linked lists of edge_stream_t. - - Generate torrc.{complete|sample}.in, tor.1.in, the HTML manual, and the - online config documentation from a single source. - - It would be potentially helpful to respond to https requests on - the OR port by acting like an HTTPS server. - - - We should get smarter about handling address resolve failures, or - addresses that resolve to local IPs. It would be neat to retry - them, since right now we just close the stream. But we need to - make sure we don't retry them on the same exit as before. But if - we mark the circuit, then any user who types "localhost" will - cycle through circuits till they run out of retries. See bug 872. - -Can anybody remember why we wanted to do this and/or what it means? - - config option __ControllerLimit that hangs up if there are a limit - of controller connections already. - [This was mwenge's idea. The idea is that a Tor controller can - "fill" Tor's controller slot quota, so jerks can't do cross-protocol - attacks like the http form attack. -RD] - - Bridge issues - . Ask all directory questions to bridge via BEGIN_DIR. - - use the bridges for dir fetches even when our dirport is open. - - drop 'authority' queries if they're to our own identity key; accept - them otherwise. - - give extend_info_t a router_purpose again - - - -If somebody wants to do this in some version, they should: - - Create packages for Maemo/Nokia 800/810, requested by Chris Soghoian - - debian already makes ARM-arch debs, can maemo use these asks - phobos? - - More work on AvoidDiskWrites - - Make DNSPort support TCP DNS. - - -* * * * Roger, please sort these: * * * * - - - bridge communities with local bridge authorities: - - clients who have a password configured decide to ask their bridge - authority for a networkstatus - - be able to have bridges that aren't in your torrc. save them in - state file, etc. - - Consider if we can solve: the Tor client doesn't know what flags - its bridge has (since it only gets the descriptor), so it can't - make decisions based on Fast or Stable. - - Some mechanism for specifying that we want to stop using a cached - bridge. - -======================================================================= - -Future versions: - - - Protocol - - Our current approach to block attempts to use Tor as a single-hop proxy - is pretty lame; we should get a better one. - - Allow small cells and large cells on the same network? - - Cell buffering and resending. This will allow us to handle broken - circuits as long as the endpoints don't break, plus will allow - connection (tls session key) rotation. - - Implement Morphmix, so we can compare its behavior, complexity, - etc. But see paper breaking morphmix. - - Other transport. HTTP, udp, rdp, airhook, etc. May have to do our own - link crypto, unless we can bully DTLS into it. - - Need a relay teardown cell, separate from one-way ends. - (Pending a user who needs this) - - Handle half-open connections: right now we don't support all TCP - streams, at least according to the protocol. But we handle all that - we've seen in the wild. - (Pending a user who needs this) - - - Directory system - - BEGIN_DIR items - - handle connect-dir streams that don't have a chosen_exit_name set. - - Have a "Faster" status flag that means it. Fast2, Fast4, Fast8? - - Add an option (related to AvoidDiskWrites) to disable directory - caching. (Is this actually a good idea??) - X Add d64 and fp64 along-side d and fp so people can paste status - entries into a url. since + is a valid base64 char, only allow one - at a time. Consider adding to controller as well. - [abandoned for lack of demand] - - Some back-out mechanism for auto-approval on authorities - - a way of rolling back approvals to before a timestamp - - Consider minion-like fingerprint file/log combination. - X Have new people be in limbo and need to demonstrate usefulness - before we approve them. - - - Hidden services: - d Standby/hotswap/redundant hidden services: needs a proposal. - - you can insert a hidserv descriptor via the controller. - - auth mechanisms to let hidden service midpoint and responder filter - connection requests: proposal 121. - - Let each hidden service (or other thing) specify its own - OutboundBindAddress? - - - Server operation - - If the server is spewing complaints about raising your ulimit -n, - we should add a note about this to the server descriptor so other - people can notice too. - - When we hit a funny error from a dir request (eg 403 forbidden), - but tor is working and happy otherwise, and we haven't seen many - such errors recently, then don't warn about it. - - - Controller - - Implement missing status events and accompanying getinfos - - DIR_REACHABLE - - BAD_DIR_RESPONSE (Unexpected directory response; maybe we're behind - a firewall.) - - BAD_PROXY (Bad http or https proxy) - - UNRECOGNIZED_ROUTER (a nickname we asked for is unavailable) - - Status events related to hibernation - - something about failing to parse our address? - from resolve_my_address() in config.c - - sketchy OS, sketchy threading - - too many onions queued: threading problems or slow CPU? - - Implement missing status event fields: - - TIMEOUT on CHECKING_REACHABILITY - - GETINFO status/client, status/server, status/general: There should be - some way to learn which status events are currently "in effect." - We should specify which these are, what format they appear in, and so - on. - - More information in events: - - Include bandwidth breakdown by conn->type in BW events. - - Change circuit status events to give more details, like purpose, - whether they're internal, when they become dirty, when they become - too dirty for further circuits, etc. - - Change stream status events analogously. - - Expose more information via getinfo: - - import and export rendezvous descriptors - - Review all static fields for additional candidates - - Allow EXTENDCIRCUIT to unknown server. - - We need some way to adjust server status, and to tell tor not to - download directories/network-status, and a way to force a download. - - Make everything work with hidden services - - - Performance/resources - - per-conn write buckets - - separate config options for read vs write limiting - (It's hard to support read > write, since we need better - congestion control to avoid overfull buffers there. So, - defer the whole thing.) - - Rate limit exit connections to a given destination -- this helps - us play nice with websites when Tor users want to crawl them; it - also introduces DoS opportunities. - - Consider truncating rather than destroying failed circuits, - in order to save the effort of restarting. There are security - issues here that need thinking, though. - - Handle full buffers without totally borking - - Rate-limit OR and directory connections overall and per-IP and - maybe per subnet. - - - Misc - - Hold-open-until-flushed now works by accident; it should work by - design. - - Display the reasons in 'destroy' and 'truncated' cells under - some circumstances? - - Make router_is_general_exit() a bit smarter once we're sure what - it's for. - - Automatically determine what ports are reachable and start using - those, if circuits aren't working and it's a pattern we - recognize ("port 443 worked once and port 9001 keeps not - working"). - - - Security - - some better fix for bug #516? - - Directory guards - - Mini-SoaT: - - Servers might check certs for known-good ssl websites, and if - they come back self-signed, declare themselves to be - non-exits. Similar to how we test for broken/evil dns now. - - Authorities should try using exits for http to connect to some - URLS (specified in a configuration file, so as not to make the - List Of Things Not To Censor completely obvious) and ask them - for results. Exits that don't give good answers should have - the BadExit flag set. - - Alternatively, authorities should be able to import opinions - from Snakes on a Tor. - - Bind to random port when making outgoing connections to Tor servers, - to reduce remote sniping attacks. - - Audit everything to make sure rend and intro points are just as - likely to be us as not. - - Do something to prevent spurious EXTEND cells from making - middleman nodes connect all over. Rate-limit failed - connections, perhaps? - - DoS protection: TLS puzzles, public key ops, bandwidth exhaustion. - - - Needs thinking - - Now that we're avoiding exits when picking non-exit positions, - we need to consider how to pick nodes for internal circuits. If - we avoid exits for all positions, we skew the load balancing. If - we accept exits for all positions, we leak whether it's an - internal circuit at every step. If we accept exits only at the - last hop, we reintroduce Lasse's attacks from the Oakland paper. - - - Windows server usability - - Solve the ENOBUFS problem. - - make tor's use of openssl operate on buffers rather than sockets, - so we can make use of libevent's buffer paradigm once it has one. - - make tor's use of libevent tolerate either the socket or the - buffer paradigm; includes unifying the functions in connect.c. - - We need a getrlimit equivalent on Windows so we can reserve some - file descriptors for saving files, etc. Otherwise we'll trigger - asserts when we're out of file descriptors and crash. - - - Documentation - - a way to generate the website diagrams from source, so we can - translate them as utf-8 text rather than with gimp. (svg? or - imagemagick?) - . Flesh out options_description array in src/or/config.c - . multiple sample torrc files - - Refactor tor man page to divide generally useful options from - less useful ones? - - Add a doxygen style checker to make check-spaces so nick doesn't drift - too far from arma's undocumented styleguide. Also, document that - styleguide in HACKING. (See r9634 for example.) - - exactly one space at beginning and at end of comments, except i - guess when there's line-length pressure. - - if we refer to a function name, put a () after it. - - only write foo when foo is an argument to this function. - - doxygen comments must always end in some form of punctuation. - - capitalize the first sentence in the doxygen comment, except - when you shouldn't. - - avoid spelling errors and incorrect comments. ;) - - - Packaging - - The Debian package now uses --verify-config when (re)starting, - to distinguish configuration errors from other errors. Perhaps - the RPM and other startup scripts should too? - - add a "default.action" file to the tor/vidalia bundle so we can - fix the https thing in the default configuration: - https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#PrivoxyWeirdSSLPort - - -======================================================================= - -Documentation, non-version-specific. - - Specs - - Mark up spec; note unclear points about servers -NR - write a spec appendix for 'being nice with tor' - - Specify the keys and key rotation schedules and stuff - . Finish path-spec.txt - - Mention controller libs someplace. - - Remove need for HACKING file. - - document http://wiki.noreply.org/noreply/TheOnionRouter/TransparentProxy on freebsd and osx -P - figure out rpm spec files for bundles of vidalia-tor-polipo -P - figure out polipo install scripts for bundles of vidalia-tor-polipo on osx, win32 - - figure out selinux policy for tor -P - change packaging system to more automated and specific for each - platform, suggested by Paul Wouter -P - Setup repos for redhat and suse rpms & start signing the rpms the - way package management apps prefer - -Website: -J . tor-in-the-media page -P - Figure out licenses for website material. - (Phobos reccomends the Open Publication License with Option A at - http://opencontent.org/openpub/) -P - put the logo on the website, in source form, so people can put it on - stickers directly, etc. -P - put the source image for the stickers on the website, so people can - print their own -P - figure out a license for the logos and docs we publish (trademark -figures into this) - (Phobos reccomends the Open Publication License with Option A at - http://opencontent.org/openpub/) -I - add a page for localizing all tor's components. - - It would be neat if we had a single place that described _all_ the - tor-related tools you can use, and what they give you, and how well they - work. Right now, we don't give a lot of guidance wrt - torbutton/foxproxy/privoxy/polipo in any consistent place. -P - create a 'blog badge' for tor fans to link to and feature on their - blogs. A sample is at http://interloper.org/tmp/tor/tor-button.png - - More prominently, we should have a recommended apps list. - - recommend pidgin (gaim is renamed) - - unrecommend IE because of ftp:// bug. - - Addenda to tor-design - - we should add a preamble to tor-design saying it's out of date. - - we should add an appendix or errata on what's changed. - - - Tor mirrors - - make a mailing list with the mirror operators - o make an automated tool to check /project/trace/ at mirrors to - learn which ones are lagging behind. - - auto (or manually) cull the mirrors that are broken; and - contact their operator? - - a set of instructions for mirror operators to make their apaches - serve our charsets correctly, and bonus points for language - negotiation. - - figure out how to load-balance the downloads across mirrors? - - ponder how to get users to learn that they should google for - "tor mirrors" if the main site is blocked. - - find a mirror volunteer to coordinate all of this -