[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #28181 [Core Tor/Tor]: spec: Add to pt-spec.txt control messages going back to main process (tor)
#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs