summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2010-07-06 18:10:53 -0400
committerNick Mathewson <nickm@torproject.org>2010-07-06 18:10:53 -0400
commitf72c6f91deed6b076fd730d049c3bddbbb3eb329 (patch)
tree40774a32eddf909b135001a962f90e55d50d61fd
parenta9edb0b4f67825a11647c8faefa613d704be44ae (diff)
downloadtor-f72c6f91deed6b076fd730d049c3bddbbb3eb329.tar.gz
tor-f72c6f91deed6b076fd730d049c3bddbbb3eb329.zip
Remove TODO items that are either done or moved to the tracker
-rw-r--r--doc/TODO.02225
-rw-r--r--doc/TODO.future7
2 files changed, 4 insertions, 28 deletions
diff --git a/doc/TODO.022 b/doc/TODO.022
index f4fe2ebb2a..d83ed6e671 100644
--- a/doc/TODO.022
+++ b/doc/TODO.022
@@ -8,29 +8,16 @@ NOTE 2: It's easy to list stuff like this with no time estimates and
0.2.2, figure out how long the stuff we want will take, and
triage accordingly, or vice versa.
-- Design only
- - Begin design work for UDP transition; identify areas where we need to
- make changes or instrument stuff early.
- [multiple weeks, ongoing. Need to do a draft early.]
-
- Performance, mostly protocol-neutral.
- - Work with Libevent 2.0's bufferevent interface
- - Identify any performance stuff we need to push back into
- libevent to make it as fast as we want.
- - Get a decent rate-limiting feature into Libevent
- - Get openssl support into Libevent.
- - Revise how we do bandwidth limiting and round-robining between
+ 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
+ . Revise how we do bandwidth limiting and round-robining between
connections.
- Better flow-control to avoid filling buffers on routers.
- - Split AES across cores if possible.
- - Split SSL across cores (reach; may require Libevent 2.1).
-
- 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?
@@ -58,10 +45,6 @@ NOTE 2: It's easy to list stuff like this with no time estimates and
- 158: microdescriptors
o Revise proposal
- Implement
- o 160: list bandwidth in consensus
- o Finish proposal
- o and actually set it reasonably
- o and actually use it.
- Proposals to improve and implement if not broken
D IPv6 support. (Parts of 117, but figure out how to handle DNS
@@ -104,6 +87,6 @@ M? - Write proposal
- Switch to MSI on win32
- Use Thandy, perhaps?
-- Deprecations
- - Make .exit safe, or make it off-by-default.
+o Deprecations
+ o Make .exit safe, or make it off-by-default.
diff --git a/doc/TODO.future b/doc/TODO.future
index 4220799574..85e07aa921 100644
--- a/doc/TODO.future
+++ b/doc/TODO.future
@@ -22,7 +22,6 @@ K - Karsten claims
=======================================================================
Later, unless people want to implement them now:
- - tor as a socks proxy should accept (and ignore) password auth
- 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
@@ -30,10 +29,6 @@ Later, unless people want to implement them now:
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]
- - Let tor dir mirrors proxy connections to the tor download site, so
- if you know a bridge you can fetch the tor software.
- - when somebody uses the controlport as an http proxy, give them
- a "tor isn't an http proxy" error too like we do for the socks port.
- MAYBE kill stalled circuits rather than stalled connections. This is
possible thanks to cell queues, but we need to consider the anonymity
implications.
@@ -45,8 +40,6 @@ Later, unless people want to implement them now:
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.
- - Make the timestamp granularity on logs configurable, with default
- of "1 second". This might make some kinds of after-the-fact attack harder.
- We should get smarter about handling address resolve failures, or
addresses that resolve to local IPs. It would be neat to retry