Have sbws client launch tor itself
Created by: pastly
Stem can do it. https://stem.torproject.org/api/process.html
But I'm not sure we should. In fact, while it sounds cool, I'm leaning towards "don't do this."
Advantages:
-
Most/all of the Tor options for sbws client are no longer necessary. sbws can configure Tor exactly how it wants. In fact, it can tell Tor to pick whatever it wants for a SocksPort, and sbws can use the ControlPort to figure out what was chosen)
-
On the client side, the user doesn't even need to think about Tor as long as they have it installed.
-
If sbws ever happened to need a custom Tor or a newer Tor than is commonly found in package managers (which I really hope is never the case), then implementing this the right way allows for the user to specify a custom path to their desired Tor
Disadvantages/unanswered questions:
-
It's unclear what should happen for commands that need Tor but don't run continuously. Right now there are not any, but
sbws generate
might in the future. Should they really have to spend some time bootstrapping Tor just to determine the value of a consensus parameter? -
What should happen if
sbws client
is running, using its Tor process, and we then run some other sbws command that requires Tor? Should another Tor process be started? Should it detect that an "sbws-owned Tor" already exists and use it?
Random thoughts about implementation details:
-
Put the Tor data directory in
~/.sbws/tordata
. Could also put it in a fresh temporary directory every run, but I'm not sure that's a good idea. -
By default sbws should look for
tor
in the user's$PATH
. But if some config option is set (say for exampletor_bin
in the section[tor]
), it should use that instead. -
If Sbws cannot find Tor, it should only fail hard when running a command that requires it
-
It's probably possible to support both "use the system Tor that's already running" and "launch our own Tor" cases, but for simplicity's sake, I think we should only support one or the other.