Re: [tor-bugs] #5018 [Tor]: don't start ClientTransportPlugin proxies until we have a bridge that wants them

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#5018: don't start ClientTransportPlugin proxies until we have a bridge that wants
them
---------------------------+------------------------------------------------
 Reporter:  arma           |          Owner:                    
     Type:  defect         |         Status:  new               
 Priority:  normal         |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor            |        Version:                    
 Keywords:  pt tor-bridge  |         Parent:                    
   Points:                 |   Actualpoints:                    
---------------------------+------------------------------------------------
Description changed by arma:

Old description:

> Eventually we want to ship the standard Vidalia bundle with a set of
> supported client transports. We don't want to launch all of the possible
> transports when Tor starts, because most users won't ever configure a
> bridge line that asks for a given transport.
>
> So the client managed transports should launch only when we are
> configured to use a bridge that needs them.
>
> And maybe they could be closed after we no longer have any bridges that
> need them. That could certainly wait and be considered a "later feature"
> though.
>
> Do we foresee any client transports that would want to start earlier than
> when a bridge shows up that wants to use them? I guess that ties into
> #5010.
>
> Another option would be for Vidalia to paw through your bridge lines and
> know to setconf a given ClientTransportPlugin line when it sees a certain
> type of bridge line. Putting the smarts in Vidalia is probably a poor
> choice though.
>
> [I'm not sure which component this should be in -- either a Tor one or
> the pluggable transport one. Picking the one Nick is more likely to see,
> for now.]
>
> [I'm also not sure which milestone to use. We can push it back to 0.2.4
> if it's too much like a feature. That would mean that our "normal clients
> using pluggable transports" bundles will want to use 0.2.4.]

New description:

 Eventually we want to ship the standard Tor Browser Bundle with a set of
 supported client transports. We don't want to launch all of the possible
 transports when Tor starts, because most users won't ever configure a
 bridge line that asks for a given transport.

 So the client managed transports should launch only when we are configured
 to use a bridge that needs them.

 And maybe they could be closed after we no longer have any bridges that
 need them. That could certainly wait and be considered a "later feature"
 though.

 Do we foresee any client transports that would want to start earlier than
 when a bridge shows up that wants to use them? I guess that ties into
 #5010.

 Another option would be for Vidalia to paw through your bridge lines and
 know to setconf a given ClientTransportPlugin line when it sees a certain
 type of bridge line. Putting the smarts in Vidalia is probably a poor
 choice though.

 [I'm not sure which component this should be in -- either a Tor one or the
 pluggable transport one. Picking the one Nick is more likely to see, for
 now.]

 [I'm also not sure which milestone to use. We can push it back to 0.2.4 if
 it's too much like a feature. That would mean that our "normal clients
 using pluggable transports" bundles will want to use 0.2.4.]

--

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5018#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs