Remove the obsolete doc/TODO.* files

Closes bug #7730.

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.

doc/TODO.021

@@ -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?
-

doc/TODO.022

@@ -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.
-

doc/TODO.external

@@ -1,4 +0,0 @@
-
-[This file moved to svn in /projects/todo/. More people can edit
-it more easily there. -RD]
-

doc/TODO.future

@@ -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 <b>foo</b> 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
-