On Mon, 16 Feb 2015 19:35:58 +0000 Michael Rogers michael@briarproject.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
(CCing the hidden-services list.)
(Wonder if my reply will bounce.)
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.
Yep. I suspect that well behaved applications won't need this for the most part, but by defining things this way, it avoids unpleasant surprises for apps that aren't written well, or those that do try to share a tor instance.
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)?
I haven't looked at other concerns in depth, and AFAIK it's a huge problem area. My concerns in this area are more "does my branch make the current situation any worse", rather than "solve all the control port problems, and make sure this is totally a safe/fine/recommended thing to do" (It's none of those things).
If most if not all apps will set _OwningControllerProcess, the current behavior doesn't hurt either since the tor instance will die anyway, and on the off chance that someone writes a not-so-great app (heaven forbid), the right thing happens.
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?
I have this mindset too.