Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
bridgestrap
bridgestrap
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 4
    • Issues 4
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • 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.

  • The Tor Project
  • Anti-censorship
  • bridgestrapbridgestrap
  • Issues
  • #9

Closed
Open
Opened Nov 24, 2020 by Roger Dingledine@armaDeveloper

Stream transport lines from bridge auth to bridgestrap more continuously

In tpo/core/tor#30477 we've been working on having Tor bridges not test their reachability themselves, but instead tell users to check the 'status' page offered by rdsys, which uses test results from bridgestrap tests. That is, we test reachability on the server side, from a central place which knows what obfs4 is (and which is the same place as bridgedb runs so there isn't any more exposed surface area).

But currently, Serge exports its Tor bridge data to bridgedb/rdsys twice an hour in a cron job, which means there will be a many-minute delay between when you start your bridge, and when bridgestrap learns about it and commences a test. We should make that delay much shorter.

The plan in this ticket is to essentially watch Serge's cached-extrainfo.new file for "^transport " lines, and send them via a stream to rdsys, so it can have advance notice of freshly published bridges.

The advance notice doesn't have to be perfect (it can hear duplicates, and miss some) because the idea is that rdsys would still learn all its bridges the old way (via the twice-an-hour cron) too.

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: tpo/anti-censorship/bridgestrap#9