[tor-dev] RFC: Ephemeral Hidden Services via the Control Port
Michael Rogers
michael at briarproject.org
Mon Feb 16 19:35:58 UTC 2015
-----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-----
More information about the tor-dev
mailing list