-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
(CCing the hidden-services list.)
On 16/02/15 16:11, Leif Ryge wrote:
If someone has a suggestion for an alternative interface that can handle applications crashing (possibly before they persist the list of HSes they need to clean up), applications that are just poorly written (and not cleaning up all the ephemeral HSes), and (optionally, though lacking this would be a reduction in features) limiting cross application HS enumeration, I'd be more inclined to change things.
First, thanks for doing this! I think it's a great feature which will make it much easier to create new hidden service applications.
Seconded!
I like the idea of tying HS lifetime to the control port connection for the reasons you state, namely that cleanup is automatic when applications crash.
As an app developer this strikes me as the right approach. But having said that, I wouldn't actually need this feature because Briar already uses __OwningControllerProcess to shut down Tor if the control connection is closed. I imagine the same would apply to any app that manages its own Tor process - so this feature would only be useful for apps that share a Tor process with other apps and communicate directly with it via the control port, rather than indirectly via a controller such as Orbot.
Are there any such apps, and is it a good idea to support such apps (has the rest of the control protocol been examined for cross-controller data leaks, what happens if apps tread on each other's configuration changes, etc)?
However, it seems like in the case of applications which are not HS-specific this will necessitate keeping another process running just to keep the HS alive.
Dormant processes are essentially free, so does this matter?
Cheers, Michael