nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-10 05:03:43 +01:00
Code Issues Packages Projects Releases Wiki Activity

a new TODO file with more details

Browse Source 
svn:r155
This commit is contained in:
Roger Dingledine 2003-02-14 04:09:56 +00:00
parent 0bc8dc1314
commit add81a7a65
3 changed files with 105 additions and 104 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
README
View File

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

203
TODO
View File

@ -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
Data stream anonymizing, HTTP/FTP (Privoxy, Squid), SMTP, etc.
Packet Redirector, a la FreeBSD (DNS, authenticated connections, etc.)
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.
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?
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.

2
configure.in
View File

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