George Kadianakis desnacked@riseup.net 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.