Pluggable transports desideratum: reporting generic errors not related to PT negotiation

[David Fifield]

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.

[David Fifield]

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.

The PT 2 Draft 1 spec requires that transport plugins write output lines
like ENV-ERROR and VERSION-ERROR to stderr, not stdout.
https://www.pluggabletransports.info/spec/pt2draft1
3.3.2: "The 'VERSION-ERROR' message is used to signal that....
As this is an error, this message is written to STDERR."
"The 'ENV-ERROR' message is used to.... As this is an error,
this message is written to STDERR."
I don't think the draft yet addresses how to report a generic error at
any point during runtime.