[tor-dev] prop224: What should we do with torrc options?

[meejah]

David Goulet <dgoulet at ev0ke.net> writes:

> 1) Once v3 is released, from that point on _no_ v2 service will be allowed to
>    be created by "tor" itself. It will always be possible to do it by hand by
>    creating an RSA key and putting it in the service directory (see 3
>    below).

+1 or +2 at least :)

> Ok here it is. Please comment, improve, or propose! :)

How does ADD_ONION fit in?

I think the ephemeral interface is really good, and IME integrators
prefer it -- if they're already "handing secret stuff" (which seems
fairly likely, if they're aware of Tor and are integrating it in their
application) then it makes more sense for them to use this API.

Also, it's right now extremely unlikely (and in any case very fragile)
to actually succesffully add a service to a running Tor via "SETCONF" --
so I think anything using the control-protocol will typically prefer
ADD_ONION. If you want to use the filesystem/torrc approach, txtorcon
will always launch a new Tor instance for you (maybe this is the best
way to go anyway for "Tor-integrating applications"?)

All that said, I'm not suggesting the torrc/"filesystem" options go
away! These are already familiar to most service operators, presumably,
and your approach sounds great! It's also really easy to support from a
controller perspective. Also, the backwards-compatibility is very nice
too.

-- 
meejah