#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs