[tor-bugs] #28181 [Core Tor/Tor]: spec: Add to pt-spec.txt control messages going back to main process (tor)

[Tor Bug Tracker & Wiki]

#28181: spec: Add to pt-spec.txt control messages going back to main process (tor)
-------------------------------------------------+-------------------------
 Reporter:  dgoulet                              |          Owner:  dgoulet
     Type:  enhancement                          |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.6.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-spec, tor-pt, 036-roadmap-       |  Actual Points:
  subtask                                        |
Parent ID:  #28180                               |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor8
-------------------------------------------------+-------------------------
Changes (by dcf):

 * cc: dcf (added)


Comment:

 My desideratum for this is a way to report a generic error at any time,
 before or after bootstrapping, and have the error message appear in the
 tor log.

 A problem with pt-spec as it stands is that when a transport plugin
 encounters a fatal runtime error, the most it can do is write to its own
 log file (e.g. meek-client.log or obfs4proxy.log). The tor log only
 reports an [[#20451|unspecific message]]: "The communication stream of
 managed proxy '%s' is '%s'. Most probably the managed proxy stopped
 running. This might be a bug of the managed proxy, a bug of Tor, or a
 misconfiguration. Please enable logging on your managed proxy and check
 the logs for errors."

 This sucks for debugging because in order to get the actual error message,
 the user has to hack a torrc file to enable a PT-specific debug log, run
 Tor Browser again, let it fail again, and then inspect the PT-specific log
 file. If transport plugins had a way to cause a message to appear in the
 tor log, the user could just "Copy Tor Log to Clipboard" in Tor Launcher.

 The poor error reporting is so bad for usability that we have applied some
 workarounds to make sure that early errors get reported with `CMETHOD-
 ERROR` or `SMETHOD-ERROR`, because those error strings go to the tor log.
 For example [https://gitweb.torproject.org/pluggable-
 transports/meek.git/tree/meek-client/meek-
 client.go?id=8a5c6a9cdc4dc37ba77bb041ee48a4320689cc9d#n390 here], we use
 `CMETHOD-ERROR` to report a failure to open the log file, even though we
 haven't yet gotten any `CMETHOD` lines from the parent process. Otherwise
 failure to open the log file is almost impossible to diagnose!

 I wrote about this [https://groups.google.com/d/msg/traffic-
 obf/LWT_3sOrBJk/zQFvkzDyAQAJ previously] on the traffic-obf list. Quoting
 here:
 > > I ran into an issue that isn't well served by the Tor pt-spec. A
 user's meek-client was failing and not even leaving a log. The Tor log
 said only "the communications stream is closed." It turns out that they
 didn't have permission to write to the log file they had configured, so
 meek-client was failing very early. meek-client was writing an error
 message to stderr, which was ignored by Tor. This made it hard to identify
 the cause of the problem.
 > >     https://bugs.torproject.org/20451
 > >
 > > The pt-spec offers only these ways for a transport plugin to report an
 error:
 > >  * `VERSION-ERROR`
 > >  * `ENV-ERROR`
 > >  * `CMETHOD-ERROR`
 > >  * `SMETHOD-ERROR`
 > >  * `PROXY-ERROR`
 > > None of these is really appropriate for this situation. I discovered
 that you can (mis)use `CMETHOD-ERROR`, `SMETHOD-ERROR`, or `PROXY-ERROR`
 and then Tor will record the error in its log, even if Tor didn't request
 a corresponding `CMETHOD`, `SMETHOD`, or proxy.
 > >
 > > I can imagine that the same thing could happen for other reasons, for
 example bad command line syntax, or some other error could happen even
 once connections are established that the transport plugin would want to
 report back to its parent process.
 >
 > Three years ago we had a discussion (and a patch that was never merged)
 to treat anything written to stderr as an error message (currently tor
 ignores the stderr of transport plugins):
 >       https://bugs.torproject.org/9957
 >       > 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.
 >
 > The question came up again when we were discussing what to do if a
 transport plugin can't create a directory at startup.
 >       https://bugs.torproject.org/12088#comment:9
 >       > About error reporting: suppose your transport needs to create
 its own subdirectories in the state dir. You call `pt.MakeStateDir`, then
 you manually create the directories inside it. Suppose the creation of one
 of these directories fails. Is that an `ENV-ERROR`? If not, then a failure
 to create the state dir itself probably should also not be an `ENV-ERROR`.
 (Except to the extent that we abuse `ENV-ERROR` as a general-purpose error
 logging function.)
 >       >
 >       > `CMETHOD-ERROR`/`SMETHOD-ERROR` could be a good way to report
 these kinds of generic errors that happen at startup. "`CMETHOD-ERROR` foo
 failed to create state directory." The only thing is I bet application
 authors want to handle all the state dir stuff once at the top of their
 program, before they enter the `CMETHOD` processing loop. It kind of makes
 me wish for a `GENERIC-ERROR` that could appear at any time during
 negotiation.

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