ahf / goptlib Public

The loop logic assumed that there was at least one handler running when
a signal was received; if there were none, it would wait forever for a
handler event to happen.

Cf. https://bugs.torproject.org/24875

pt-spec.txt 0ef45b97b1a935489335fc31d625c463b076c1e3
196-transport-control-ports.txt f59e8f5b2819842fe6cb5b162a9226a4f1891b4d

It would always panic with a the message
	keyword "PROXY-ERROR %s\n" contains forbidden bytes

The ProxyError test currently panics because of a bug in ProxyError.

--- FAIL: TestErrors (0.00s)
panic: keyword "PROXY-ERROR %s\n" contains forbidden bytes [recovered]
        panic: keyword "PROXY-ERROR %s\n" contains forbidden bytes

Before, if you set TOR_PT_EXTENDED_SERVER_PORT but not
TOR_PT_AUTH_COOKIE_FILE, you would get the misleading error message:
	ENV-ERROR need TOR_PT_ORPORT or TOR_PT_EXTENDED_SERVER_PORT environment variable
Now you get:
	ENV-ERROR need TOR_PT_AUTH_COOKIE_FILE environment variable with TOR_PT_EXTENDED_SERVER_PORT

It was never implemented and is no longer part of the specification:
https://trac.torproject.org/projects/tor/ticket/15612

The arguments to ClientSetup and ServerSetup that were solely to handle
"*" are now documented as unused.

This means that anything that is not a net.Error, or is a net.Error but
is not Temporary, should be considered to be a permanent error by the
caller. Sample code now shows the new error-checking convention.
Previously, we used the convention that a non-net.Error should be
considered temporary, because it could have been caused by a failed
SOCKS negotiation, for example. Now those errors are simply not returned
to the caller. See https://trac.torproject.org/projects/tor/ticket/14135.

In summary, previous behavior is this:
	net.Error, Temporary:     caller should try again
	net.Error, non-Temporary: caller should quit
	other errors:             caller should try again
It is now this:
	net.Error, Temporary:     caller should try again
	net.Error, non-Temporary: caller should quit
	other errors:             caller should quit
But now the "other errors" such as those caused by a bad SOCKS
negotiation will not be reported by AcceptSocks.

The practical effect of this change is almost nil; even if callers don't
update their error-checking code, the only change is in the "other
errors" that don't arise in normal use.

https://trac.torproject.org/projects/tor/ticket/12125

Adds two new functions:
	ProxyError
	ProxyDone
and one new member to ClientInfo:
	ProxyURL *url.URL

At least until #12538 is done.

See https://trac.torproject.org/projects/tor/ticket/14135. We're going
to make the recommended way to check for an error from AcceptSocks match
the way in the golang standard library:
	if e, ok := err.(net.Error); ok && e.Temporary() {
		continue
	} else {
		break
	}
The new tests check that 1) AcceptSocks faithfully represents an
underlying Accept error with respect to its net.Error-ness and its
Temporary-ness, and 2) errors that happen post-Accept in AcceptSocks are
either silently swallowed or else reported as a Temporary net.Error.

The test fails at the moment: "socks_test.go:267: AcceptSocks returned
non-net.Error: unexpected EOF".

The change is designed to be transparent to calling code and implements
enough of RFC1928/RFC1929 such that pluggable transports can be written.

Notable incompatibilities/limitations:
 * GSSAPI authentication is not supported.
 * BND.ADDR/BND.PORT in responses is always "0.0.0.0:0" instead of the
   bound address/port of the outgoing socket.
 * RFC1929 Username/Password authentication is setup exclusively for
   pluggable transport arguments.
 * The BIND and UDP ASSOCIATE commands are not supported.

Workaround for tor bug #15240.

This works around tor bug #15240, where the ExtORPort cookie is
generated after the pluggable transports are launched, leading to a
race condition and DialOr failures.

'ServerInfo.AuthCookie' is deprecated by this change, replaced by
'ServerInfo.AuthCookiePath', however nothing external to goptlib should
be using either value in most situations.