Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • P pluggable transports
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 5
    • Issues 5
    • List
    • Boards
    • Service Desk
    • Milestones
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Jobs
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Anti-censorship
  • Pluggable Transports
  • pluggable transports
  • Issues
  • #10629

Closed
Open
Created Jan 14, 2014 by Ximin Luo@infinity0

PT spec changes for better interoperability with other projects

I spoke with the i2p guys today and here are some of their suggestions for the PT spec. These would make it easier for them (and future other projects) to use Tor's PTs.

Major improvements:

  • better spec documentation
    • less Tor jargon, split Tor-specific information into separate sections (e.g. Tor env vars)
    • some guidelines for non-Tor programs to use PTs
  • better handling of per-endpoint config params such as pubkeys, instead of current hack via SOCKS auth params

Smaller enhancements, "good to have":

  • possibility of letting a single process to act as both a client (outgoing) and server (incoming).
  • flashproxy must allow client-specific remote endpoints (already as legacy/trac#10196 (closed))
  • don't trust the entire localhost machine to make outgoing connections, e.g. if one users wants to run his own instance. two options here:
    • SSL connection with user/pass to the SOCKS transport client
    • use unix domain sockets. This also frees up ports, which is extra-useful in PT composition. Doesn't work on windows, though.
Assignee
Assign to
Time tracking