Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • bridgestrap bridgestrap
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 10
    • Issues 10
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Anti-censorship
  • bridgestrapbridgestrap
  • Issues
  • #9
Closed
Open
Created Nov 24, 2020 by Roger Dingledine@armaDeveloper

Stream transport lines from bridge auth to bridgestrap more continuously

In tpo/core/tor#30477 (closed) 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
Time tracking