[tor-bugs] #5085 [Obfsproxy]: managed obfsproxy does not quit if tor dies

[Tor Bug Tracker & Wiki]

#5085: managed obfsproxy does not quit if tor dies
---------------------------+--------------------
     Reporter:  arma       |      Owner:  asn
         Type:  defect     |     Status:  new
     Priority:  minor      |  Milestone:
    Component:  Obfsproxy  |    Version:
   Resolution:             |   Keywords:
Actual Points:             |  Parent ID:  #10047
       Points:             |
---------------------------+--------------------

Comment (by dcf):

 I had to solve this problem for meek-client-torbrowser on Windows. meek-
 client-torbrowser starts two of its own subprocesses, and on Windows, tor
 kills its PTs uncleanly with TerminateProcess (#9330), hence they don't
 have a chance to clean up their subprocesses.

 What I did was described in comment:5:ticket:10047. You stick another
 process (called terminateprocess-buffer) in between tor and the real PT
 (meek-client-torbrowser). tor kills terminateprocess-buffer uncleanly. The
 real PT senses that its stdin has closed, and uses that as a signal to
 shut down cleanly.

 How this would work in the obfsproxy case is you would put the buffer
 process in between tor and obfsproxy, and modify obfsproxy to monitor the
 closedness of its stdin.

 The buffer source code looks like this: https://gitweb.torproject.org
 /pluggable-
 transports/meek.git/blob/ff595f26a6be2c4ca58637e04c012b804e69617e
 :/terminateprocess-buffer/terminateprocess-buffer.go.

 Unfortunately, tor closes the stdin of its PT processes on startup, so the
 PT has to know whether it is being run with a terminateprocess-buffer or
 not, and interpret the closing of stdin appropriately. In meek-client-
 torbrowser, this is done with a special --exit-on-stdin-eof option.

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