Opened 7 years ago

Closed 3 years ago

Last modified 20 months ago

#3725 closed defect (wontfix)

Implement the wildcard "*" protocol in {Client,Server}TransportPlugin lines

Reported by: asn Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: #3591 Points:
Reviewer: Sponsor:

Description

The spec says:

  If instead of a transport method, the torrc lists "*" for a managed
  proxy, Tor uses that proxy for all transport methods that the plugin
  supports. So "ClientTransportPlugin * exec /usr/libexec/tor/foobar"
  tells Tor that Tor should use the foobar plugin for every method that
  the proxy supports. See the "Managed proxy interface" section below
  for details on how Tor learns which methods a plugin supports.

Child Tickets

Change History (13)

comment:1 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-final

ISTR that asn's pending patch which I should review any day now might do this. If so, great! If not, it can wait for 0.2.4.

comment:2 Changed 7 years ago by asn

I don't think I have a pending patch implementing this.

comment:3 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.4.x-final

comment:4 Changed 6 years ago by nickm

Keywords: tor-client added

comment:5 Changed 6 years ago by nickm

Component: Tor ClientTor

comment:6 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:7 Changed 6 years ago by asn

Note to self: This gets messy when we want to use the wildcard transport _and_ also specify bindaddrs to the transports of a server transport plugin.

comment:8 Changed 6 years ago by asn

This problem seems solvable, even though all the solutions I've
thought of are messy. Example of such a silly solution:

When Tor uses the wildcard transport in TOR_SERVER_TRANSPORTS, it also
places all the bindaddrs for all the transport it knows (from its
state file) to its TOR_PT_SERVER_BINDADDR environment variable. When the
transport proxy supports a transport that is also mentioned in the
_BINDADDR variable, it knows in which port to bind.

For example, if a transport proxy supports the pluggable transports
"one" and "two", and Tor in its state file has saved bindaddrs for the
transports "two", "sixteen" and "thirty", it will create the following
env vars:

TOR_PT_SERVER_TRANSPORTS="*"
TOR_PT_SERVER_BINDADDR="two-0.0.0.0:1444;sixteen-0.0.0.0:1201;thirty-0.0.0.0:1001

and the transport proxy will try to bind "two" to "0.0.0.0:1444" and
"one" to whichever port it wants.

In any case, I'll try to think of a better solution to this problem, since the above is kinda lame.

comment:9 in reply to:  8 Changed 5 years ago by dcf

Replying to asn:

When Tor uses the wildcard transport in TOR_SERVER_TRANSPORTS, it also
places all the bindaddrs for all the transport it knows (from its
state file) to its TOR_PT_SERVER_BINDADDR environment variable. When the
transport proxy supports a transport that is also mentioned in the
_BINDADDR variable, it knows in which port to bind.

This is the way I naturally interpreted the spec. You bind server ports that are

  1. listed in TOR_PT_SERVER_BINDADDR
  2. AND listed in TOR_PT_SERVER_TRANSPORTS
  3. AND are one of our supported transports.

It's the intersection of three sets. When TOR_PT_SERVER_TRANSPORTS=*, you skip step 2 (i.e., intersect with the universe).

https://gitweb.torproject.org/pluggable-transports/goptlib.git/blob/78e518c824d9541056ba2ca870df2bb01b810b05:/pt.go#l304

comment:10 Changed 4 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:11 Changed 3 years ago by asn

Resolution: wontfix
Status: newclosed

As decided in #10131, WONTFIXing this in favor of #15612.

comment:12 Changed 21 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:13 Changed 20 months ago by nickm

Milestone: Tor: 0.3.???

Milestone deleted

Note: See TracTickets for help on using tickets.