On Mon, 16 Feb 2015 16:11:55 +0000 Leif Ryge <leif@xxxxxxxxxxxxx> wrote: [snippity] > 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. I'd rather see two modes: one as you > describe, and another in which the ephemeral HS stays running until a > new control port connection requests that it be stopped. To avoid > allowing enumeration of running services, the "stop" command could > require that the requestor already knows some details of the HS - > either a cookie generated at creation time, or perhaps just the > private key that was provided when it was started. dgoulet suggested "Detach=true" as an optional argument, which is what the add side interface would look like if I did this. > This of course wouldn't result in crashed applications' HSes being > cleaned up automatically, but having a few stale HSes sitting around > isn't the end of the world. One approach for cleaning them up could > be that tor could remove them automatically after it sees connection > refused a few times. I'm not quite sure how I feel about this yet. The code for doing all of this isn't that difficult, but I'd want to hear from a few more people about what the right thing to do here would be. Most importantly since the `ADD_EPH_HS` interface uses key/value pairs for the port/target now, this would be easy to add on at a later date even if it doesn't get included in the first iteration. Something to discuss at the dev-meeting if consensus hasn't been reached by then. Regards, -- Yawning Angel
Attachment:
pgpUDV1fv6jLC.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev