a new TODO file with more details

  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:

  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.

[First four are all equally first.

Others follow in order of priority.]

Patch well-known proxies to make them OR compliant

   Data stream anonymizing, HTTP/FTP (Privoxy, Squid), SMTP, etc.

   Packet Redirector, a la FreeBSD (DNS, authenticated connections, etc.)

Legend:

SPEC!!  - Not specified

SPEC    - Spec not finalized

        - Not done

        * Top priority

        . Partially done

        o Done

        D Deferred

        X Abandoned

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

Deploy and manage open source development site.

Manage and maintain code, write documentation, design and write

 unit tests, handle patch submissions, make the autoconf work, etc

Deploy a widespread network: manage deployment.

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.

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.

AC_INIT

AM_INIT_AUTOMAKE(tor, 0.0.1)

AM_INIT_AUTOMAKE(tor, 0.0.2pre4)

AM_CONFIG_HEADER(orconfig.h)

CFLAGS="-Wall -O2"