Yawning Angel yawning@schwanenlied.me writes:
Cool! I added a quick try at using this in txtorcon, with an example; see the following branch:
https://github.com/meejah/txtorcon/tree/yawning-feature-6411
(Most of that example code would actually end up in the endpoint.listen() code and be hidden from most users of the library, too. And would be the default instead of "launch a new tor").
This does not support `HiddenServiceAuthorizeClient` yet in any way (neither basic nor stealth). It may in the future, but coming up with a sane interface for it is way more pain than I am willing to self-inflict at the moment.
What about a similar API: add + remove a client-key. And similarly, you could push a key yourself, or ask for a new one. The only difference would be including the onion-address. Like:
ADD_EPH_HS_ADD_CLIENT_AUTH kittenmeowae41f nickname0 stealth NEW:BEST ADD_EPH_HS_ADD_CLIENT_AUTH kittenmeowae41f nickname1 basic NEW:BEST
The return value would be the cookie (for basic) or both the cookie and the key-blob for stealth. Or "NEW:BEST" could be "RSA1024:....." like the other API?
For deleting you'd pass the onion ID and the nickname I guess. Like:
ADD_EPH_HS_DEL_CLIENT_AUTH kittenmeowae41f nickname1
- meejah suggested that ephemeral hidden services should have their lifetime tied to the originating control port connection. I think this is a good idea, but this would be the only control port command that does this sort of thing.
__OwningControllerProcess is similar, I guess, but instead ties to the whole lifetime of Tor (which sounds way easier to implement ;)
Questions, comments, feedback appreciated,
I think it's looking quite nice!