[tor-bugs] #7016 [Flashproxy]: Make flashproxy-client a managed proxy.

[Tor Bug Tracker & Wiki]

#7016: Make flashproxy-client a managed proxy.
-------------------------+--------------------------------------------------
 Reporter:  dcf          |          Owner:  dcf         
     Type:  enhancement  |         Status:  needs_review
 Priority:  normal       |      Milestone:              
Component:  Flashproxy   |        Version:              
 Keywords:               |         Parent:              
   Points:               |   Actualpoints:              
-------------------------+--------------------------------------------------

Comment(by dcf):

 Thank you for the review.

 > Although, I'm wondering: why did you implement proposal 180 on your own
 and didn't use pyptlib? The main reason we wrote pyptlib is so that you
 don't have to implement proposal 180. Did you not like the API, did you
 find the documentation unreadable, or did you just want to implement
 something on your own?

 I'm sorry about that; it was a combination of laziness and ignorance. When
 I first tried pyptlib over the summer, I was afraid of how it used monocle
 and wanted me to use its event loop, which would not have worked for
 `flashproxy-client`. Then I heard that you were reimplementing it using
 Twisted, and was still unsure. Now I see that pyptlib does not do anything
 besides the env/stdout part of proposal 180, which I think is a good idea.
 I had already started implementing #5575 in a language other than Python,
 so I understood proposal 180 well enough to plug in the new code.

 > In any case, the code looks good. Did you test it with Tor? Does it
 work?

 It works; the environment variables and writing to stdout worked as soon
 as I remembered to flush stdout. I also set the local listening port to 0
 so that it is chosen by the OS in managed mode.

 > > Some thoughts:
 > > * It uses a `--managed` option. Maybe, since this is planned to be the
 most standard use, `--managed` should be the default and `--external` be
 an option?
 >
 > Yeah, I've been thinking about this myself too.
 >
 > I still haven't decided if it would be helpful (because you don't have
 to append --managed in the end of the ClientTransportPlugin line), or
 confusing (who try to execute 'flashproxy' and get "ENV-ERROR Cannot find
 TOR_PT_STATE_LOC" in stdout) to people.

 I think I will do this. We can detect when the user is running from a tty,
 for example, and give a nice error message to stderr.
 {{{
 VERSION-ERROR no-version
 If you are running flashproxy-client from the command line and not
 from a ClientTransportPlugin configuration line, you must use the
 --external option.
 }}}

 > > * What's the best way to ship a default `torrc`? I am using the path
 `./flashproxy-client` in the
 [https://gitweb.torproject.org/user/dcf/flashproxy.git/blob/refs/heads/managed:/torrc
 torrc], which works if you run from the source directory, but not if you
 install to `/usr/local/bin`.
 >
 > Hm, what do you mean?
 >
 > If you are asking how you would spawn flashpproxy in a Tor Browser
 Bundle; you would probably have a `ClientTransportPlugin` line like this:
 > `ClientTransportPlugin websocket exec ./App/flashproxy-client --managed`
 > and `flashproxy-client` would be placed in the top-level `/App/`
 directory of the Tor Browser Bundle.

 I can see how it will work for a TBB. I am thinking of someone who
 downloads the flashproxy-client package and does `make install`. They will
 have to edit the included `torrc` in order to make it point to
 `/usr/local/bin`. They will also have to find a place to store the
 `torrc`. I was just wondering if there was a standard way to do this for
 people who download obfsproxy by itself.

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