[tor-dev] On Controller, Tor process structure, client software

[Sebastian G. <bastik.tor>]

Hi,

This should be just input, nothing too serious.

I'm not interested in any kind of feedback. It's probably not worth it.
Feel free to use this thread to refer to changes. I'm also not
interested in discussions involving me. Feel free do discuss this anyway.

It has to be more detailed and the controller itself has to be more
modular as well.

I hope the attached txt file came through and looks like it should,
where it would not look great when dumped into this message.

Good Luck.

Regards,
Sebastian

--
everything evolves into decay
-------------- next part --------------
Controller (Vidalia) parses its configuration file and lauchnes Launcher; can control and kill Tor; can read and write, but not delete torrc
	Launcher lauchnes the updater (Thandy); can launch Tor, pluggable transports; can't kill any process
		Thandy reads its configuration file and updates what I should without Tor; Thandy tells the launcher that Tor is required to update if that's the case
		Launcher parses the torrc for pluggable transports and starts them
			Pluggable transports start and do what has been configured in the torrc
		Launcher starts Tor, and Tor-connect after the updater told it to do so or that it can do it, because updates are done; Launcher tells Thandy that it started Tor
			Tor opens socks-ports and awaits (local) connections; can't kill and create processes, can't open non-local ports
			Tor-connect opens ports to connect to other machines and to listen for incomming connections (bridge/relay)
		Launcher starts Tor-http if the torrc says so
				Tor-http opens http ports specified in the torrc
			Thandy fetches the updates and remembers its state, applies updates right away or on the next run (if background updates are not possible)
				Controller and Tor including required components are running, Thandy and Launcher exited after they did their job (update, start everything it should)
					User wants TorBrowser to start and selects it from a menu in the Controller (if browers are fixed any browser can be used)
						Controller queries a local database to see what "TorBrowser" is and figures out that's a browser
						(The database contains information about what a given application supports like socks or http and what stream isolation is appropiate and if it's safe to use with Tor)
							Controller makes Tor open a socks or http port, maybe both, with the appropiate isolation
								Controller starts the launcher and tells it to open TorBrower and make it connect to the ports Tor opened for it
									Launcher start TorBrowser and makes it connect to such ports, then it exits
										Controller, Tor and TorBrowser are running (if there's a sane way to control Tor from within the Browser, well OK)
											Closing the Browser has the following effect
												Controller and Tor are runnning, the browser is not
					User wants Thunderbird to start and picks "Launch ... tor-aware" in the Controller
						Controller presents a dialog to select what should be lauchned "tor-aware"
							Controller queries a local database and checks if it can be used safely with Tor and what it supports (Socks/http)
								Controller warns the user if there's no entry or it's known to be unsafe, tells the user about TorBirdy
									Controller makes Tor open the required ports, if required, could set username and password for isolation
									Controller starts the Lauchner and tells it to start Thunderbird including which ports it should connect to (maybe how to identify)
										Launcher starts Thunderbrid and makes it connect to the ports the Controller told it, then it exits
											Controller, Tor and Thunderbird are running
					User wants his/her favorite IRC client to start (he/she could still pick "Launch ...") and types "Controller --start XIRC"
						Controller queries a local database and checks what "XIRC" (hope that does not exist, example) supports and if it's safe
							Controller warns the user if that isn't found in the database or unsafe
								Controller makes Tor open the required ports with the desired isolation
									Controller starts the launcher and tells it what to start and to which ports it should connect
										Launcher starts XIRC and makes it connect to those ports, then it exits
											Controller, Tor and XIRC are running
											
END

You get the idea.

The isolation process can be far more detailed. I assume it's easier to control and isolate processes rather than modules.
The controller can only launch the Launcher.
Tor has to be able to write to disk to create log files and write its state file. Tor-connect doesn't have to write to disk, therefore any exploit in networking and stream handling can't do much damage.
The controller is what controls Tor. From the point of security a controller within the browser is hard to isolate. If the browser has a hole Tor's behavior can be modified. I'm not against it. For task like "New Identity" it's a pain to open the Controller.
If the controller would be only inside the browser, the browser would have to be open all the time.
The launcher is only there for launching stuff, not for messing with Tor
In this dream the controller helps using whatever is safe with Tor, users don't have to think about it and they can't mis-configure it. They can't put too much load on the network because they isolate streams how it's sane.
In this dream the Controller has its own config, Thandy has its own config, Launcher would have its own, whenever needed, the rest would go into torrc.
Putting the rest in torrc might be not the cleanest solution, but it's the most user friendly. Vidalia offers to edit the torrc, which is pretty could and easy.
I see how bridge.conf, pluggable_trans.conf, http.conf etc would clean it up, but users would have to deal with them. Vidalia would have to offer to edit them one by one. Unless Vidalia reads all the files, and presents them as they would be one big file a user can edit. Upon saving it saves everything to correct file. I assume that's rather difficult.