Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • BridgeDB BridgeDB
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 25
    • Issues 25
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Anti-censorship
  • BridgeDBBridgeDB
  • Issues
  • #2895
Closed
Open
Created Apr 12, 2011 by Karsten Loesing@karsten

BridgeDB assumes that cached-descriptors[.new] are in chronological order

When parsing bridge descriptors, BridgeDB assumes that descriptors in the bridge descriptor files are in chronological order and that descriptors in cached-descriptors.new are newer than those in cached-descriptors. If this is not the case, BridgeDB overwrites a bridge's IP address and OR port with those from an older descriptor.

I think that the current cached-descriptors* files that Tor produces always have descriptors in chronological order. But once we change that, e.g., when trying to limit the number of descriptors that Tor memorizes, BridgeDB will behave funny.

We should look at the bridge descriptor that is referenced from the bridge network status by its publication time and ignore all other bridge descriptors from the same bridge.

Assignee
Assign to
Time tracking