[tor-bugs] #22042 [Core Tor/Tor]: HSFETCH not followed by HS_DESC_CONTENT event

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Apr 25 15:18:20 UTC 2017


#22042: HSFETCH not followed by HS_DESC_CONTENT event
-----------------------------+------------------------------------
 Reporter:  nickler          |          Owner:  dgoulet
     Type:  defect           |         Status:  accepted
 Priority:  Medium           |      Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor     |        Version:  Tor: 0.2.9.10
 Severity:  Normal           |     Resolution:
 Keywords:  tor-hs, control  |  Actual Points:
Parent ID:                   |         Points:  0.2
 Reviewer:                   |        Sponsor:
-----------------------------+------------------------------------

Comment (by dgoulet):

 Replying to [comment:7 nickler]:
 > Thanks for working on fixing this!
 >
 > Re "Hammering the HSDirs every 60 seconds": yeah I don't want to do
 that. But I believed that the HS descriptor would come from a local cache
 after reading the stem documentation and the spec which say something
 like:
 > "The caching behavior when fetching a descriptor using this command is
 identical to normal Tor client behavior."

 The `HSFETCH` command doesn't poke the cache, it always try to download a
 descriptor from HSDir(s). However, once downloaded, the descriptor ends up
 in the cache of the tor client you are using.

 > Where can I read more about the normal Tor client behavior with respect
 to caching? Or does this note actually refer to the lookup cache dgoulet
 mentions?

 I fear there is no documentation about it except the source code for now
 :S ... There is a client descriptor cache and an introduction point
 failure cache. Most of it is in `src/or/rendcache.c`.

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


More information about the tor-bugs mailing list