On 23 Nov (03:12:22), meejah wrote:
David Goulet dgoulet@ev0ke.net writes:
- 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.
I agree with you on the fact that ADD_ONION is nice and also crucial to hidden service as well. That will be addressed with the control port implementation of next generation. It's still an undecided part of the engineering work which is how we are going to proceed with it. Do we change the current events/commands to support both v2 and v3? Do we make new events/commands for v3? ... (#20699) It's quite a big piece of work so if anyone wants to take a stab at the specification! woot!!! :)
Thanks! David
-- meejah _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev