mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-23 20:03:31 +01:00
71 lines
2.8 KiB
Plaintext
71 lines
2.8 KiB
Plaintext
|
|
Obvious things I'd like to do that won't break anything:
|
|
|
|
* Abstract out crypto calls, 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.
|
|
|