Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #23817
Closed (moved) (moved)
Open
Created Oct 10, 2017 by teor@teor

Tor re-tries directory mirrors that it knows are missing microdescriptors

When a microdescriptor for a relay changes, it takes a while to propagate to directory mirrors. In this time, a client can:

  1. Download a consensus that references the new microdescriptor
  2. Try a directory mirror that has an older consensus, and therefore doesn't have that microdescriptor
  3. Repeat 2

This is a particular issue when:

  • the client first bootstraps, and the fallback or authority provides a newer consensus than any of its directory mirrors
  • the client has been asleep for a while, and its consensus has expired, so it fetches one straight away
  • only 1/3 of a client's directory guards has the new consensus

We can fix this by:

  • making clients try the same directory mirror for their consensus and microdescriptors
  • making clients avoid directory mirrors with missing microdescriptors
  • making clients use a fallback when all of their directory mirrors don't have a microdescriptor

This issue affects primary guards and v3 onion services.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking