Re: [tor-dev] How to query HS hostname from control port

[meejah <meejah@xxxxxxxxx>]

George Kadianakis <desnacked@xxxxxxxxxx> writes:

> I guess a side question here is why those GETINFO commands only return the
> ephemeral onion services and not all of them.
>
> We should probably provide a common interface for getting the hostname of onion
> services, regardless of whether they are ephemeral or permanent. Also, by
> making this a control port command, Tor libraries can fetch it without doing
> weird filesystem IO.

Personally, I think usage should preferentially go to "the new way"
(ADD_ONION) since there's no really good way to hide the fact that the
torrc "HiddenServiceDir" API *is* "weird filesystem IO". For example, if
you want the private key, then you need to do "weird filesystem IO".

Practically speaking: txtorcon would still need to do filesystem stuff,
*and* control-port stuff to support any reasonable API for old vs new
onion services (i.e. a .get_private_key() method or knowing what to do
when the user changes something, like the ports list -- some are
impossible to change, some need SETCONF, etc.)


I believe I'm correct that the original use-case is to give a process
control-port access but *not* read-access to the private-key, right? So
this is fulfilled by doing "detach=true" to ADD_ONION (where you'll get
back the onion but not the private key). Of course, then there is no way
to re-start this hidden-service -- is that part of the use-case?

I still feel like I don't really understand what problem the original
use-case is trying to solve, though: "something" is creating some torrc
changes and hidden-service dirs and then starting a thing that has
control-port access. Could the original thing just pass in the service
address to use?

> Anyone who wants to open a ticket here, or has a counter argument? :)

As a *slight* counter-argument to adding on-disk services to the
GETINFO, that would make it harder to distinguish between on-disk
services and ADD_ONION -based ones. Not sure how much of a practical
problem this is, though (worst-case would be that a controller would
have to load all 'hostname' files to confirm which ones are on-disk
vs. ADD_ONION). Perhaps a *third* GETINFO, e.g. "GETINFO
onions/permanent" would be safest...?

I have tried pretty hard to synthesize a unified API to "hidden
services" (see release-1.x branch of txtorcon), and it's actually rather
hard. So I'm not sure there's *any* value in trying to paper over the
differences (at the control-protocol layer) by providing "one" API to
get the hidden-service addresses -- any controller library is still
going to need to distinguish all 6 flavours (permanent vs ephemeral,
authenticated or not, stealth-auth or not). There's almost nothing
completely common -- e.g. stealth-auth'd services have N onion-address,
so there's not even "an" address.

-- 
meejah
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev