[tor-bugs] #9957 [Tor]: Tor should consider stderr output of transport proxies

[Tor Bug Tracker & Wiki]

#9957: Tor should consider stderr output of transport proxies
--------------------+---------------------
 Reporter:  wfn     |          Owner:
     Type:  defect  |         Status:  new
 Priority:  minor   |      Milestone:
Component:  Tor     |        Version:
 Keywords:  tor-pt  |  Actual Points:
Parent ID:          |         Points:
--------------------+---------------------
 Currently, Tor cares about what transport proxies (e.g. obfsproxy) say
 over stdout (it echoes stdout in its log, etc.) Not so with stderr, the
 reason being, as far as I can tell, the presumed/standard signaling
 channel for transport proxies to communicate with Tor is their standard
 output stream, as per design.

 It so happens that as of now, obfsproxy may complain about some things
 (e.g. it not being able to write to its own log file) over stderr. If one
 runs obfsproxy as intended (using the ServerTransportPlugin directive in
 torrc), obfsproxy may exit (Tor will report this, of course) without any
 verbal explanation.

 Using the "run a transport proxy manually (without Tor) to figure out
 what's wrong" method (which some bridge operators have (had) to resort to
 (that is, at least me and someone else who talked with asn)) in order to
 debug things seems suboptimal.

 Three ways out, as I see it:

  1. Make sure all transport proxies adhere to the "use stdout to complain
 about things" protocol.

  2. Have Tor treat both stdout and stderr streams of transport proxies as
 meaningful, and include their contents in log. This requires changing the
 design in regards to transport proxy <-> Tor signaling channels.

  3. Care about stderr instead of stdout (most easy in terms of code
 changes, I think; not sure if makes much sense / is elegant, though.)

 Are there any specific design-level nuances that block option 2?

 For option 2, the
 [https://gitweb.torproject.org/tor.git/blob/43f95e38abefced37ad24966d56298e972cebf81:/src/common/util.c#l4483
 tor_get_lines_from_handle() function] seems to be overall more or less
 handle-type-agnostic; it uses variable names like "stdout_buf", but it all
 really depends on what's passed via "handle", which could be any kind of
 stream.

 [https://gitweb.torproject.org/tor.git/blob/43f95e38abefced37ad24966d56298e972cebf81:/src/or/transports.c#l596
 configure_proxy() in or/transports.c] is what would need changing.
 Depending on design changes, the streams would have to be combined, or
 (simply) stderr would have to be used instead of stdout (so to remain
 clean, there'd need to be a tor_process_get_stderr_pipe(), which would
 simply {{{return process_handle->stderr_pipe}}}).

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