[tor-bugs] #3474 [Pluggable transport]: obfsproxy managed proxies support

[Tor Bug Tracker & Wiki]

#3474: obfsproxy managed proxies support
---------------------------------+------------------------------------------
 Reporter:  asn                  |          Owner:  asn  
     Type:  defect               |         Status:  new  
 Priority:  normal               |      Milestone:       
Component:  Pluggable transport  |        Version:       
 Keywords:                       |         Parent:  #3591
   Points:                       |   Actualpoints:       
---------------------------------+------------------------------------------

Comment(by asn):

 Replying to [comment:4 nickm]:
 > Why have a separate notion of managed_proxy_params_t ?  Why not have one
 configuration data structure that gets initialized from the command line
 if we're not in managed mode, and from the environment if we are?

 I'm still stuck on thinking on this.

 I'm going to rebuild my branch to be based on Zack's more-protocols
 branch.
 Zack's more-protocols branch introduces the config_t structure (instead of
 protocol_params_t), which contains the protocol_vtable and arbitrary
 hidden protocol-specific data.

 Nick, this means that the stateful proxy-to-transport structure, you
 proposed in IRC some weeks ago, can't happen, since the transport
 structure is hidden in the abstraction of config_t.

 Zooming out a bit, ideally, I would like the module writer to not care
 about managed or external proxies at all. I would like the module writer
 to define a (*config_create) which would do it for both managed and
 external proxies. The problem is that I can't find a nice way to do this.

 Specifically, in the case of external proxies the whole argv slice has to
 be passed to the protocol. In the case of managed proxies, at least
 bindaddr and ORPort have to be passed to the protocol, so that it fills
 its *_params_t accordingly.
 I can't see how separate config_create_managed() and
 config_create_external() can be avoided [0].

 Additionally, an obfsproxy_params_t (or something) might be needed in both
 cases, so as to contain global obfsproxy information like the location to
 store transports state, tor's extended OR port, etc.

 [0]:
 config_t *(*config_create_external)(int n_options, const char *const
 *options);
 config_t *(*config_create_managed)(int is_server, char *bindaddr, char
 *orport);
 ... or something.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3474#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online