Re: [tor-bugs] #14219 [Tor]: Visiting a down hidden service that was recently up results in many hsdesc fetches

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#14219: Visiting a down hidden service that was recently up results in many hsdesc
fetches
------------------------+-------------------------------------------
     Reporter:  arma    |      Owner:
         Type:  defect  |     Status:  needs_review
     Priority:  normal  |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  SponsorR, tor-hs 025-backport
Actual Points:          |  Parent ID:
       Points:          |
------------------------+-------------------------------------------

Comment (by arma):

 Replying to [comment:7 nickm]:
 > BTW, what was that "Do we already have this descriptor" check supposed
 to prevent, if anything?

 Oh ho! Careful here, if you haven't been following the (somewhat twisty)
 design.

 That "do we have this descriptor" check was part of the following design:

 When we receive a new stream request for a hidden service:
 A) If we don't already have a copy of the descriptor, fetch one, and parse
 it so we have a local copy of the struct.
 B) Try all the intro points, removing each intro point from our local copy
 of the struct each time we get a definitive NACK from that intro point.
 C) If we run out of intro points (i.e. our local copy of the struct says
 the hs has no intro points), fetch the descriptor again, in case it had
 changed since our original one.
 D) If the new one is indeed different, parse it and replace our local copy
 of the struct. Else, don't replace.
 E) If it is still the case that there are no intro points in the local
 copy of our struct, fail. Else goto step B.

 So the choice in 'D' of whether to replace our local copy of the struct is
 critical to whether we remember that those intro points had given us
 NACKs. We used to ask "is the desc exactly the same", which is very
 similar to "would replacing the local copy of the struct just give us back
 those failed intro points". Now we ask "was it published on the same
 second", which we pretend is just as similar. It probably is in practice.

 It ain't pretty and you can't dance to it, etc etc.

 > marking for possible 0.2.5 backport as branch "bug14219_025" in my
 public repo

 Now I'll let you reconsider whether backporting is a good idea. :)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14219#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs