Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #1852

Closed (moved)
Open
Opened Aug 21, 2010 by Roger Dingledine@arma

Tor clients should remember bridge info across restarts

In Tor 0.2.2.x if you stop your Tor client, it forgets everything it's learned about its bridges. So when you start it again, it just goes back to the torrc file to learn which bridges it should try.

We need to teach Tor how to remember bridge fingerprints, reachability, longevity, IP addresses, etc across restarts.

Step one is to brainstorm about the range of information we might remember, and how we can learn it, and how we might use it productively. This part will be tricky -- for example, right now we remember bridge descriptors across restarts, but we don't use them because we don't know whether they're fresh enough.

Step two is to design a format for the state file, so we can capture everything we want to capture in a future-compatible way.

Step three is to design a protocol (i.e. write a proposal) by which Tor clients can learn new bridge lines in-band, e.g. by asking the bridge authority for some more (perhaps the new bridges will be a function of the current bridges; but that's a separate proposal). We should make sure the results of this project are compatible with that protocol.

Step four is to prioritize the items from step one, and implement the key ones (learning, storing, and using).

Part of step four might turn out to be "refactor Tor's use of entry guards and bridges in circuitbuild.c", since right now it's increasingly turning into a hacked together mess.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#1852