a new TODO file with more details

svn:r155

README

@@ -32,7 +32,7 @@ Dependencies:
   For tor itself, you're going to need openssl (0.9.5 or later
   -- including the dev stuff and includes). If you're on Linux,
   everything will probably work fine. OS X and BSD (but see below under
-  troubleshooting) now work too. Let us know if you get it working
+  troubleshooting) may work too. Let us know if you get it working
   elsewhere.
 
 If you got the source from cvs:
@@ -90,7 +90,7 @@ How to use it:
 
   For more convenient command-line use, I recommend making a ~/.wgetrc
   with the line
-    http_proxy=localhost:8118
+    http_proxy=http://localhost:8118
   Then you can do things like "wget seul.org" and watch as it downloads
   from the onion routing network.
 

TODO

@@ -1,106 +1,107 @@
-[First four are all equally first.
-Others follow in order of priority.]
 
-Patch well-known proxies to make them OR compliant
+Legend:
-   Data stream anonymizing, HTTP/FTP (Privoxy, Squid), SMTP, etc.
+SPEC!!  - Not specified
-   Packet Redirector, a la FreeBSD (DNS, authenticated connections, etc.)
+SPEC    - Spec not finalized
-
+        - Not done
-Deploy and manage open source development site.
+        * Top priority
-Manage and maintain code, write documentation, design and write
+        . Partially done
- unit tests, handle patch submissions, make the autoconf work, etc
+        o Done
-
+        D Deferred
-Deploy a widespread network: manage deployment.
+        X Abandoned
-Maintain and distribute directory/network state information etc. Keep
-operators and users happy.
-
-Test OR network for reliability and performance, with and without
- mechanisms for throttling, congestion control, padding, load balancing
- if applicable, etc.
-     Use httperf and webload to get some performance stats
-     Modify code as dictated by testing.
-
-Develop rendezvous points
-Implement reply onions
-Develop location protected servers idea
-
-Enhance router twins to do load balancing as well as DoS prevention
-
-Develop and deploy automated reputation management, directory servers,
-and directory/network state monitoring.
-
----
-
-debian / red hat spec file
-handle starting things as a system daemon
-transition addr to sin_addr
-get proxy to choose the same conn if it's open
-
-Obvious things I'd like to do that won't break anything:
-
-* Abstract out crypto calls (done), with the eventual goal of moving
-  from openssl to something with a more flexible license.
-
-* Test suite. We need one.
-
-* Since my OR can handle multiple circuits through a given OP,
-  I think it's clear that the OP should pass new create cells through the
-  same channel. Thus we can take advantage of the padding we're already
-  getting. Does that mean the choose_onion functions should be changed
-  to always pick a favorite OR first, so the OP can minimize the number
-  of outgoing connections it must sustain?
-
-* Figure out what .h files we're actually using, and how portable
-  those are.
-
-* Exit policies. Since we don't really know what protocol is being spoken,
-  it really comes down to an IP range and port range that we
-  allow/disallow. The 'application' connection can evaluate it and make
-  a decision.
-
-* We currently block on gethostbyname at the exit. This is poor. We need
-  to set it up so we have a separate process that we talk to. There are
-  some free software versions we can use, but they'll still be tricky.
-
-* I'd like a cleaner interface for the configuration files, keys, etc.
-  Perhaps the next step is a central repository where we download router
-  lists? We can aim to make use of the directory servers that Mixminion
-  deploys.
-
-* ORs should rotate their link keys periodically. Later.
-
-* The parts of the code that say 'FIXME'
-
-* Clean up the number of places that get to look at prkey. Later.
-
-* Circuits should expire sometime, say, when circuit->expire triggers?
-  Later.
 
 
+        . Topics / circuits
+                o Implement topics
+                - Rotate circuits after N minutes?
+                - Circuits should expire when circuit->expire triggers
+                - Handle half-open connections
+        . Clean up the event loop (optimize and sanitize)
+        - Exit policies
+                - Path selection algorithms
+                        - Let user request certain nodes
+                        - And disallow certain nodes
+                        - Choose path by jurisdiction, etc?
+        - Implement our own memory management, at least for common structs
+        . Appropriate logging
+                - Come up with convention for what log level means what
+                - Make code follow convention
+        . Terminology
+                o Circuits, topics, cells stay named that
+                - 'Connection' gets divided, or renamed, or something?
+        . DNS farm
+                o Distribute queries onto the farm, get answers
+                o Preemptively grow a new worker before he's needed
+                - Prune workers when too many are idle
+                - Keep track of which connections are in dns_wait
+                - Need to cache positives/negatives on the tor side
+                        - Keep track of which queries have been asked
+                - Better error handling when
+                        - An address doesn't resolve
+                        - We have max workers running
+        . Directory servers
+                - Automated reputation management
+                - Include key in source; sign directories
+                - Have directories list recommended-versions
+                        - Quit if running the wrong version
+                        - Command-line option to override quit
+                . Add more information to directory server entries
+                        - Exit policies
+                        - jurisdiction? others?
+SPEC!!          - Figure out how to do threshold directory servers
+        . Scrubbing proxies
+                - Find an smtp proxy?
+                - Find an ftp proxy? Figure out how that would work?
+                - Wait until there are packet redirectors for Linux
+                . Get socks4a support into Mozilla
+        . Get tor to act like a socks server
+                o socks4, socks4a
+                - socks5
+SPEC!!          - Handle socks commands other than connect, eg, bind?
+        - Develop rendezvous points
+        D Implement reply onions
+        D Deploy and manage open source development site.
+        . Documentation
+                . Discussion of socks, tsocks, etc
+                - On-the-network protocol
+                        - Onions
+                        - Cells
+                . Better comments for functions!
+        - Tests
+                - Testing harness/infrastructure
+                - Unit tests
+                - System tests (how?)
+                - Performance tests, so we know when we've improved
+                        . webload infrastructure (Bruce)
+                        . httperf infrastructure (easy to set up)
+                        . oprofile (installed in RH 8.0)
+        D Deploy a widespread network
+        . Router twins
+                o Choose twin if primary is down, when laying circuit
+                - Load balancing between twins
+                        - Keep track of load over links/nodes, to
+                          know who's hosed
+        - Daemonize and package
+                - Teach it to fork and background
+                - Red Hat spec file
+                - Debian spec file equivalent
+                
+        . Autoconf
+                . Which .h files are we actually using? Port to:
+                        o Linux
+                        o BSD
+                        . Solaris
+                        . Windows
+        . Move away from openssl
+                o Abstract out crypto calls
+                - Look at ndss, others? Just include code?
+
+        . transition addr to sin_addr (huh?)
+
+        . Clean up the number of places that get to look at prkey
+SPEC!!  - Non-clique topologies, clearer bandwidth management
+        . Look at OR handshake in more detail
+                - Spec it
+                - Merge OR and OP handshakes?
+                - Periodic link key rotation. Spec?
 
 
-Non-obvious things I'd like to do:
-
-(Many of these topics are inter-related. It's clear that we need more
-analysis before we can guess which approaches are good.)
-
-* Currently when a connection goes down, it generates a destroy cell
-  (either in both directions or just the appropriate one). When a
-  destroy cell arrives to an OR (and it gets read after all previous
-  cells have arrived), it delivers a destroy cell for the "other side"
-  of the circuit: if the other side is an OP or App, it closes the entire
-  connection as well.
-
-  But by "a connection going down", I mean "I read eof from it". Yet
-  reading an eof simply means that it promises not to send any more
-  data. It may still be perfectly fine receiving data (read "man 2
-  shutdown"). In fact, some webservers work that way -- the client sends
-  his entire request, and when the webserver reads an eof it begins
-  its response. We currently don't support that sort of protocol; we
-  may want to switch to some sort of a two-way-destroy-ripple technique
-  (where a destroy makes its way all the way to the end of the circuit
-  before being echoed back, and data stops flowing only when a destroy
-  has been received from both sides of the circuit); this extends the
-  one-hop-ack approach that Matej used.
-
-* Reply onions. Hrm.
-

configure.in

@@ -1,6 +1,6 @@
 
 AC_INIT
-AM_INIT_AUTOMAKE(tor, 0.0.1)
+AM_INIT_AUTOMAKE(tor, 0.0.2pre4)
 AM_CONFIG_HEADER(orconfig.h)
 
 CFLAGS="-Wall -O2"