George Kadianakis <desnac...@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. -- meejah _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev