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
  • #18611

Closed (moved)
Open
Opened Mar 23, 2016 by teor@teor

Improve semantics for pluggable transports with dummy addresses

In #18517 (moved), we noted that some pluggable transports (for example, meek) use a dummy IP address in the bridge line, because the actual addresses are specified using some other method.

The address specified in the bridge line is passed by tor to the pluggable transport, which then ignores it. But there's no way for tor to know whether the address is going to be ignored.

Ignoring an address has a number of implications:

  • there's no standard IPv4 or IPv6 "dummy" address
  • even if two bridge lines use the same "dummy" address and port, bridge_resolve_conflicts should not consider them to be conflicting (Are there any more?)
  • anything that checks the address of the bridge will return erroneous results

I'm not sure there's any easy way of fixing this, but I'm writing it down so we know about it. Perhaps it needs a change to the semantics of the bridge line so we can leave out address and port if they're going to be ignored anyway.

To upload designs, you'll need to enable LFS and have 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#18611