[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #13207 [Tor]: Is rend_cache_clean_v2_descs_as_dir cutoff crazy high?

#13207: Is rend_cache_clean_v2_descs_as_dir cutoff crazy high?
----------------------+------------------------------------
 Reporter:  arma      |          Owner:  dgoulet
     Type:  defect    |         Status:  accepted
 Priority:  Medium    |      Milestone:  Tor: 0.2.9.x-final
Component:  Tor       |        Version:
 Severity:  Normal    |     Resolution:
 Keywords:  tor-hs    |  Actual Points:
Parent ID:  #13209    |         Points:  medium
  Sponsor:  SponsorR  |
----------------------+------------------------------------
Changes (by dgoulet):

 * priority:  High => Medium
 * version:  Tor: 0.2.7 =>
 * severity:   => Normal
 * milestone:  Tor: 0.2.8.x-final => Tor: 0.2.9.x-final


Comment:

 Moving this to 029. IMO, there are still unanswered question here on the
 HSDir behavior if we want to make that change. See below.

 > New approach: HSDirs should hold descriptors which have a publication
 time of less than 25 hours ago. We shouldn't care if the HSDir thinks it's
 responsible for the descriptor ID because this overrides the the logic for
 keeping descriptors for clients with skewed clocks.

 Basically, drop the "are we responsible for desc ID?" check, and keep any
 descriptors that matches this timestamp heuristic? This is scaring me a
 bit that is descriptor can be used to store arbitrary data on _all_ HSDirs
 instead of 6...

 I fear that without a statistics of how much clock skew on average we have
 in the network, the skew limit is a bit arbitrary. Tbh, 25 hours clock
 skew is massive for a client and even more for a service... I'm not even
 sure that service will be able to operate correctly... But let's assume we
 use that because worst case scenario, it seems there is no way we can use
 a crazy cutoff efficiently and still use the check on the descriptor ID,
 right?

 Maybe it's the start of a new era where HSDir stores all the things but
 expires them quicker?...

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13207#comment:16>
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