[tor-bugs] #10006 [Pluggable transport]: Build an obfs-flash PT bundle

[Tor Bug Tracker & Wiki]

#10006: Build an obfs-flash PT bundle
-------------------------------------+-------------------
     Reporter:  dcf                  |      Owner:  dcf
         Type:  task                 |     Status:  new
     Priority:  normal               |  Milestone:
    Component:  Pluggable transport  |    Version:
   Resolution:                       |   Keywords:
Actual Points:                       |  Parent ID:  #7167
       Points:                       |
-------------------------------------+-------------------

Comment (by dcf):

 Replying to [comment:6 infinity0]:
 > Without looking in more detail, my suspicion is that this is #9330
 showing up. When Tor kills obfs-flash-client using ProcessTerminate, exit
 handlers don't complete and so it never gets a chance to kill all the
 children completely (which would explain why you're seeming seemingly
 random children living/dying).

 #9330 is a good find. I think this problem must be a bit deeper, though.
 The thing with Vidalia refusing to run a second time would have been
 noticed in a released bundle before now. What children survive isn't
 random; it is different in each configuration above, but it was
 reproducible within each configuration. (So in the first configuration, it
 was always obfsproxy.exe and only obfsproxy.exe that survived.) Also note
 that there are two obfsproxy.exe processes: one started by tor.exe for
 `obfs2` and `obfs3` (PID 1852), and one started by obfs-flash-client.exe
 for `obfs3_flashproxy` (PID 2144); and only the second one (PID 2144) is
 continuing to run. So I think it has something to do with the process
 nesting.

 > BTW, the PT spec states that you need to SIGINT *twice* for a PT to shut
 down. When you do Ctrl-C inside the terminal on GNU/Linux, it sends SIGINT
 to *all* processes including the children, which is not what you want
 since obfsproxy/flashproxy don't yet follow the spec and die on just one
 SIGINT - you must "kill -INT" the obfs-flash-client directly, twice.
 Alternatively, obfs-flash-client (and anything using
 pyptlib.util.subproc.auto_killall) will die and clean up on one SIGTERM.

 I think one SIGINT suffices if the transport program is not currently
 handling any connections. At least that's how I read ''"Proxies should
 respond to a single INT signal by closing their listener ports and not
 accepting any new connections, but keeping all connections open, then
 terminating when connections are all closed."'' obfs-flash-server
 [https://gitweb.torproject.org/pluggable-transports/obfs-
 flash.git/blob/064dce29fce2ece3b70efac5c2131a89dd4087cd:/obfs-flash-
 server.go#l424 implements it] as I understand it. But you're right,
 neither flashproxy-client nor obfsproxy seem to have any fancy signal
 handling, so it must not be the case that obfsproxy.exe is simply waiting
 for a second signal. C-obfsproxy used to have fancy SIGINT handling
 (#3473) and there is a ticket (#9741) for py-obfsproxy. Handling of
 SIGTERM (vs. SIGINT) is #9732. I should mention that in the Python wrapper
 I tested, I registered handlers for both SIGINT and SIGTERM, and never saw
 either (probably because of #9330).

 > I'm not sure how that affects Cygwin. But on windows yesterday, I was
 able to do a clean shutdown using a standalone obfs-flash-client with
 Ctrl-C twice (although I just did that in the console, so possibly it sent
 it to the children as well).

 Ah, that's good news. What I'll do is upload one of the bundles I built,
 and then we can at least test whether this happens on other machines than
 mine.

 The other thing I would try is to have obfs-flash-client spawn a third
 dummy process, both before and after the usual two, and see if it is
 killed, or it remains alongside obfsproxy.exe, or it remains and
 obfsproxy.exe does not, etc.

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