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

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.

added component::core tor/tor parent::3591 priority::medium resolution::wontfix status::closed tor-client type::defect labels

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.

Trac:
Milestone: N/A to Tor: 0.2.3.x-final

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

Trac:
Milestone: Tor: 0.2.3.x-final to Tor: 0.2.4.x-final

Trac:
Keywords: N/A deleted, tor-client added

Trac:
Component: Tor Client to Tor

Trac:
Milestone: Tor: 0.2.4.x-final to Tor: 0.2.5.x-final

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.

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.

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

Trac:
Milestone: Tor: 0.2.5.x-final to Tor: 0.2.???

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

Trac:
Status: new to closed
Resolution: N/A to wontfix

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Milestone deleted

Trac:
Milestone: Tor: 0.3.??? to N/A

closed

mentioned in issue #5018 (moved)

mentioned in issue #10131 (moved)

mentioned in issue #15612 (moved)

moved to tpo/core/tor#3725 (closed)

mentioned in issue tpo/core/tor#15612 (closed)