#21969: We're missing descriptors for some of our primary entry guards -----------------------------------+------------------------------------ Reporter: asn | Owner: asn Type: defect | Status: assigned Priority: High | Milestone: Tor: 0.3.1.x-final Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: tor-guard, tor-bridge | Actual Points: Parent ID: | Points: 1.5 Reviewer: | Sponsor: SponsorU -----------------------------------+------------------------------------
Comment (by s7r): Replying to [comment:22 teor]: > Operators can explicitly disable DirCache, and can also disable it by setting various other options (like AccountingMax), or by having low RAM or bandwidth. Also, DirCache was only introduced in 0.2.8, and we support relays back to 0.2.4. > > So while it is true that most guards are DirCaches, not all guards will be, even in the future. > > Also, this might enable an attack/issue where a guard posts one descriptor to the directory authorities, and another to its clients. (This is avoided by using microdescriptors, because their hashes are in the consensus.) Thanks for the feedback teor. In this case we need to think about a logic where first of all a client will fetch the descriptors of the sampled guards (primary first, and move down the list to all the guards we ever connected to, until we have their descriptors). After that we download / refresh the rest of few thousands descriptors. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21969#comment:23> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs