Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port

[Michael Rogers <michael@xxxxxxxxxxxxxxxx>]

-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJU4kaeAAoJEBEET9GfxSfMP/oH/Aoel3gyOAtn5NrgKh6WRcFf
5TwPOElP/vL+XI5XrPRYJYczilQ2st/ZLu6nuULLvGoqbtDZ0VU23uyffPhypx87
n5hXPNYbXt7/tvJ42ULq509D1nRI9Xp39YOwPMt0Yw7RXWo2eB7eYd2n0tMXrdan
4hhxIqe21MXXiL9QGuf/MaToFRQP9TB2vNP5eZzS07WR1EvSN5TvBO5nZM9TRE4t
daJ0mNPhL4v6gb0j0iVCzZJFZ424swOyqdOu5K7iPRWkMbacX9uXINzjUn8NWzIO
hT6GK3dHsyhGjiWLQ0Dlpw1yIZ6vv5YCKAbYoS7mSS0U1NNSaouaT7zzR7+GIMo=
=uVVW
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev