[tor-bugs] #24610 [Core Tor/Tor]: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed

[Tor Bug Tracker & Wiki]

#24610: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed
-----------------------------+------------------------------------
 Reporter:  cypherpunks      |          Owner:  (none)
     Type:  defect           |         Status:  new
 Priority:  Medium           |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor     |        Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal           |     Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+------------------------------------

Comment (by asn):

 Both commits look reasonable to me. I think we could do a better job at
 explaining the edge-case in the first commit message because I got quite
 confused reading it (it also seems to be a different issue than the one
 described in comment:2).

 Here is the edge-case I consider:

 1) Network trouble and we end up with unreachable intro points on an HS
 desc.
 2) We start fetching new HS desc.
 3) `rend_cache_failure_clean_callback()` triggers unluckily before
 receiving new HS desc, and makes the descriptor usable again.
 4) We receive some leftover mds/consensus we asked for a few moments ago.
 This triggers `hs_client_dir_info_changed()` and we try to refetch the
 desc, but seems like the desc is now usable! Ugh bug triggers.

 The first commit should fix this scenario because now
 `can_client_refetch_desc()` will return `HS_CLIENT_FETCH_PENDING` instead
 of `HS_CLIENT_FETCH_HAVE_DESC`. I wonder if there are any other such weird
 edge-cases this patch won't fix :S

 Do we have a way to test this fix btw?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24610#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online