fire endpoint listen deferred when HS desc is desseminated

[david415]

fire endpoint listen deferred when HS desc is desseminated

Let's accurately determine the proper time to fire the Tor hidden service endpoint listen() method's returned deferred. That is, we should fire when the endpoint can actually be connected to via Tor... once the HS descriptor has been uploaded to one (or more?) HS directory authorities.

On on irc #tor-dev Yawning pointed out that they do have plans to implement a feature that might give us what we want:

https://trac.torproject.org/projects/tor/ticket/3523

17:51 < Yawning> as a sideeffect
17:51 < Yawning> that's where I saw that

17:58 < Yawning> once the patches land, a corresponding extension to the existing events will be added to the spec
17:58 < Yawning>
DonnchaC/torspec@bc34815...3523

[meejah]

Okay, so after the above command is done, there will be some kind of "descriptor uploaded" event.

[meejah]

To be clear, there's also the open question of whether the callback should fire on the first HSDir upload, or after X uploads (where X could be "all" if we can get that number from Tor).

I believe that after the first will be "acceptable", as the HS connection should work. I'm not clear on the failure cases here (e.g. what's the worst-case for a client connecting to an HS that has only uploaded one descriptor?).

One possibility might be to expose the number of descriptor uploads to user-code somehow, so they can choose (and give the callback() on the first upload, and it's up to user code to wait for more if they like). This sounds "complicated" though, so I'd rather just have txtorcon choose some (single) way to have it work.

(FWIW, right now endpoint.listen() waits for one upload, via looking at INFO log messages -- fragile, but works).

[DonnchaC]

FYI the HS_DESC UPLOADED event has been merged into Tor master now. It's included in release 0.2.7.1-alpha.

[meejah]

Great! Thanks for letting me know @DonnchaC

Now I can get rid of the giant "listen for INFO message" hack.

[david415]

yess!

On Tue, Jun 9, 2015 at 1:42 PM, meejah notifications@github.com wrote:

Great! Thanks for letting me know @DonnchaC https://github.com/DonnchaC

Now I can get rid of the giant "listen for INFO message" hack.

—
Reply to this email directly or view it on GitHub
#107 (comment).

[david415]

Has there been any work towards using the new event type?
Maybe I could help with this one...

[meejah]

I did look into this a little, but IIRC the event didn't include the onion-ID at the time, so it was guesswork anyway (i.e. you'd get "a descriptor was uploaded!" but no way to tie that back to the actual descriptor you were interested in). In "many" cases it would work fine (since you're only working with 1 hidden-service on that Tor), but ...

That said, the ephemeral-hidden-service stuff was still in flux at the time, so is very probably in better shape now and I haven't tried again recently.Tor is shortly in feature-freeze for the next release and if this stuff is "in" that next release it would be great to have txtorcon supporting it for then...

[meejah]

Okay, so UPLOAD and UPLOADED sub-events for HS_DESC are available. There's still a bit of guesswork: UPLOAD tells you that a particular key's descriptor is being uploaded to a particular dirauth. However, the UPLOADED event doesn't tell you the key (only that "some" upload to a particular dirauth has succeeded).

So, this has been implemented in master for EphemeralHiddenService, however, it will "sometimes" be wrong, I think. (If you're uploading multiple descriptors and they happen to pick the same dirauth).

TCPHiddenServiceEndpoint should be upgraded to use this method (on sufficiently new Tor's) as well.

It should also be used by the

[meejah]

This is in master and working, and is in the release-1.0-*

Any problems/bugs/enhancements should be separate tickets.