Tor should consider stderr output of transport proxies
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:
Make sure all transport proxies adhere to the "use stdout to complain about things" protocol.
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.
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 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.
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